Hi,
I would suggest splitting grass.py into several modules, e.g.
general
raster
vector
database
User could import only desired modules from 'grass' package, e.g.
from grass import raster
?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Fri, May 8, 2009 at 1:57 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
I would suggest splitting grass.py into several modules, e.g.
general
raster
vector
databaseUser could import only desired modules from 'grass' package, e.g.
from grass import raster
Sounds good to me (and move out the include stuff at the same
time).
Markus
?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Martin Landa wrote:
I would suggest splitting grass.py into several modules, e.g.
general
raster
vector
databaseUser could import only desired modules from 'grass' package, e.g.
from grass import raster
This would be a good point to consider how it relates to the SWIG
interface.
Currently, those modules are named swig.grass, swig.vector, etc. That
was done to avoid a collision over "import grass". But "swig" is a
rather generic prefix to use. I had thought about changing it from
"swig.*" to "grass.*", and renaming "grass" to e.g. "grass.script".
The question is whether e.g. "grass.vector" should contain the
functions from grass.py or the SWIG functions for the vector library.
IOW, which one gets precedence? Or should we make them equal and just
have grass.script.vector and grass.swig.vector?
And should "swig" even be visible, or should it be e.g.
"grass.lib.vector"?
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/5/8 Glynn Clements <glynn@gclements.plus.com>:
[...]
Currently, those modules are named swig.grass, swig.vector, etc. That
was done to avoid a collision over "import grass". But "swig" is a
rather generic prefix to use. I had thought about changing it from
"swig.*" to "grass.*", and renaming "grass" to e.g. "grass.script".The question is whether e.g. "grass.vector" should contain the
functions from grass.py or the SWIG functions for the vector library.
IOW, which one gets precedence? Or should we make them equal and just
have grass.script.vector and grass.swig.vector?And should "swig" even be visible, or should it be e.g.
"grass.lib.vector"?
It seems to me 'lib' as better name then 'swig'.
Done in
r37345
r37346
r37347
r37348
If no objections I will backport the changes to develbr6. I would vote
also to backport them to relbr64 (rules for Python scripting should be
same for 64/65), but it would probably require new RC (or wider
testing of wxGUI).
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Fri, May 22, 2009 at 12:14 AM, Martin Landa <landa.martin@gmail.com> wrote:
2009/5/8 Glynn Clements <glynn@gclements.plus.com>:
[...]
Currently, those modules are named swig.grass, swig.vector, etc. That
was done to avoid a collision over "import grass". But "swig" is a
rather generic prefix to use. I had thought about changing it from
"swig.*" to "grass.*", and renaming "grass" to e.g. "grass.script".The question is whether e.g. "grass.vector" should contain the
functions from grass.py or the SWIG functions for the vector library.
IOW, which one gets precedence? Or should we make them equal and just
have grass.script.vector and grass.swig.vector?And should "swig" even be visible, or should it be e.g.
"grass.lib.vector"?It seems to me 'lib' as better name then 'swig'.
Done in
r37345
r37346
r37347
r37348
Before backporting, could it be possible to move out the include part into
swig/include/
?
Here what Glynn suggested:
On Wed, May 6, 2009 at 12:13 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
in order to facilitate the creation of other bindings, I suggest to move the
swig/python/*.i
files into
swig/include/Then the various language wrappers could include from there.
common.i, grass.i, my_typemaps.i and utils.i are language-specific,
but the rest could be moved.
Markus