Hi,
is there any special reason why libgis is named in ctypes interface as
grass.py [1]. I would vote for gis.py to keep consistency in names.
Martin
[1] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/ctypes/Makefile#L16
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Martin wrote:
is there any special reason why libgis is named in ctypes
interface as grass.py [1]. I would vote for gis.py to keep
consistency in names.
fwiw, on a system with many python libraries available, I'd guess
that "import grass" was a lot more specific than "import gis".
I'd assume most people have more than one GIS software installed,
and many GIS software do python these days, so would the change
lead to conflicts? or would it just be exposed internally?
Hamish
Hi,
2011/3/8 Hamish <hamish_b@yahoo.com>:
is there any special reason why libgis is named in ctypes
interface as grass.py [1]. I would vote for gis.py to keep
consistency in names.fwiw, on a system with many python libraries available, I'd guess
that "import grass" was a lot more specific than "import gis".
you are always importing this module from the `grass` packages, so
import grass.lib.grass as grass
or
from grass.lib import grass
So I really don't see any problem here. Moreover `grass` makes
impression that it's some generic module for GRASS Python API, which
is not true. So it's confusing at the end.
import grass.lib.gis as gis
or
from grass.lib import gis
seems to be quite OK for me.
I'd assume most people have more than one GIS software installed,
and many GIS software do python these days, so would the change
lead to conflicts? or would it just be exposed internally?
You can always use
from grass.lib import gis as libgis
Current
`grass.lib.grass` seems to be weird to me, braking naming convention,
confusing for the user. What about
import grass.lib.vector
I would assume that there can me tons of packages with name 'vector'.
From this point of view 'gis' as package name is less common
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Martin Landa wrote:
is there any special reason why libgis is named in ctypes interface as
grass.py [1].
Compatibility with the old SWIG wrappers:
http://trac.osgeo.org/grass/browser/grass/trunk/swig/python/Makefile?rev=42931
Originally, the SWIG wrappers consisted of a single module named
python_grass7. When it was split into multiple modules, the libgis
wrapper was named "grass", although I don't think that there was any
particular reason behind that.
http://trac.osgeo.org/grass/changeset/35275/grass/trunk/swig/python/Makefile
I would vote for gis.py to keep consistency in names.
If we're going to do it, it should be done sooner rather than later.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2011/3/8 Glynn Clements <glynn@gclements.plus.com>:
is there any special reason why libgis is named in ctypes interface as
grass.py [1].Compatibility with the old SWIG wrappers:
http://trac.osgeo.org/grass/browser/grass/trunk/swig/python/Makefile?rev=42931
Originally, the SWIG wrappers consisted of a single module named
python_grass7. When it was split into multiple modules, the libgis
wrapper was named "grass", although I don't think that there was any
particular reason behind that.
Thanks for explanation.
http://trac.osgeo.org/grass/changeset/35275/grass/trunk/swig/python/Makefile
I would vote for gis.py to keep consistency in names.
If we're going to do it, it should be done sooner rather than later.
I would vote for that.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Wed, Mar 9, 2011 at 12:16 AM, Martin Landa <landa.martin@gmail.com> wrote:
2011/3/8 Glynn Clements <glynn@gclements.plus.com>:
...
http://trac.osgeo.org/grass/changeset/35275/grass/trunk/swig/python/Makefile
I would vote for gis.py to keep consistency in names.
If we're going to do it, it should be done sooner rather than later.
I would vote for that.
Me, too.
Markus
Hi,
2011/3/9 Markus Neteler <neteler@osgeo.org>:
http://trac.osgeo.org/grass/changeset/35275/grass/trunk/swig/python/Makefile
I would vote for gis.py to keep consistency in names.
If we're going to do it, it should be done sooner rather than later.
I would vote for that.
Me, too.
done in r45892.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
