Hi,
it's seems that currently PyGRASS doesn't support shorten parameters, eg.
Module('v.db.addcolumn', map='p5', col='vymera_ha double')
File "./u01.py", line 27, in compute
Module('v.db.addcolumn', map='p5', col='vymera_ha double')
File "/opt/src/grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/module.py",
line 347, in __init__
self.__call__(*args, **kargs)
File "/opt/src/grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/module.py",
line 395, in __call__
raise ParameterError('%s is not a valid parameter.' % key)
grass.pygrass.errors.ParameterError: col is not a valid parameter.
Any chance to change this behaviour? Thanks, Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
2014-10-22 10:49 GMT+02:00 Martin Landa <landa.martin@gmail.com>:
it's seems that currently PyGRASS doesn't support shorten parameters, eg.
there is also another issue where pyGRASS seems to be too much strict, eg.
Module('d.vect', map='p6', type='point', color='purple',
icon='basic/star', size=10)
fails with
File "./u01.py", line 37, in compute
Module('d.vect', map='p6', type='point', color='purple',
icon='basic/star', size=10)
File "/opt/src/grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/module.py",
line 347, in __init__
self.__call__(*args, **kargs)
File "/opt/src/grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/module.py",
line 387, in __call__
self.inputs[key].value = val
File "/opt/src/grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/parameter.py",
line 141, in _set_value
raise TypeError(str_err % (self.name, self.typedesc, type(value)))
TypeError: The Parameter <size>, require: float, get: <type 'int'> instead
The reason is that pyGRASS expects 'size' given as a float and not
integer. PyGRASS should do casting in this case automatically. Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Wed, Oct 22, 2014 at 10:49 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
it's seems that currently PyGRASS doesn't support shorten parameters, eg.
Module('v.db.addcolumn', map='p5', col='vymera_ha double')
[cut]
grass.pygrass.errors.ParameterError: col is not a valid parameter.
Any chance to change this behaviour?
Actually I don't like the idea of shorten parameters... 
So I wont fix this.
On Wed, Oct 22, 2014 at 11:12 AM, Martin Landa <landa.martin@gmail.com> wrote:
there is also another issue where pyGRASS seems to be too much strict, eg.
Module('d.vect', map='p6', type='point', color='purple',
icon='basic/star', size=10)
fails with
File "./u01.py", line 37, in compute
Module('d.vect', map='p6', type='point', color='purple',
icon='basic/star', size=10)
[cut]
TypeError: The Parameter <size>, require: float, get: <type 'int'> instead
The reason is that pyGRASS expects 'size' given as a float and not
integer. PyGRASS should do casting in this case automatically. Martin
This is fixed in grass71, should be backported.
2014-10-22 17:36 GMT+02:00 Pietro <peter.zamb@gmail.com>:
Any chance to change this behaviour?
Actually I don't like the idea of shorten parameters...
So I wont fix this.
well, pyGRASS should behave similarly to GRASS parser which allows
shorten options. It's not question of personal preferences I would say
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
Hi,
2014-10-22 17:37 GMT+02:00 Pietro <peter.zamb@gmail.com>:
[...]
This is fixed in grass71, should be backported.
are you planning to to this? Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On Wed, Oct 22, 2014 at 5:40 PM, Martin Landa <landa.martin@gmail.com> wrote:
2014-10-22 17:36 GMT+02:00 Pietro <peter.zamb@gmail.com>:
Any chance to change this behaviour?
Actually I don't like the idea of shorten parameters...
So I wont fix this.
well, pyGRASS should behave similarly to GRASS parser which allows
shorten options. It's not question of personal preferences I would say
Let say that is not a priority for me, so if someone want to add this
"feature" no problem.
On Wed, Oct 22, 2014 at 5:45 PM, Martin Landa <landa.martin@gmail.com> wrote:
This is fixed in grass71, should be backported.
are you planning to to this? Martin
Yes, I would like to do it...
The main problem are the difference between grass70 and grass71 on the
exception...
I would like to backport grass.exceptions and then backport all the
pygrass from grass71 to grass70.
If other devs agree on backporting grass.exceptions, then I could do
this during the weekend.
Hi,
2014-10-22 18:09 GMT+02:00 Pietro <peter.zamb@gmail.com>:
If other devs agree on backporting grass.exceptions, then I could do
this during the weekend.
I would agree with that. Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On 22 October 2014 18:10, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
Hi,
2014-10-22 18:09 GMT+02:00 Pietro <peter.zamb@gmail.com>:
If other devs agree on backporting grass.exceptions, then I could do
this during the weekend.
I would agree with that. Martin
+1
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On Wed, Oct 22, 2014 at 11:40 AM, Martin Landa <landa.martin@gmail.com>
wrote:
2014-10-22 17:36 GMT+02:00 Pietro <peter.zamb@gmail.com>:
>> Any chance to change this behaviour?
>
> Actually I don't like the idea of shorten parameters...
> So I wont fix this.
well, pyGRASS should behave similarly to GRASS parser which allows
shorten options. It's not question of personal preferences I would say
I don't think shortening should be supported in pygrass. Short names are
convenient when typing the commands in shell. Pygrass is more for scripting
so short names are not such an advantage, the opposite I would say. And
it's not pythonic at all, so it could confuse people with Python background.
Anna
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Anna Petrášová wrote:
> >> Any chance to change this behaviour?
> >
> > Actually I don't like the idea of shorten parameters...
> > So I wont fix this.
>
> well, pyGRASS should behave similarly to GRASS parser which allows
> shorten options. It's not question of personal preferences I would say
>
>
I don't think shortening should be supported in pygrass. Short names are
convenient when typing the commands in shell. Pygrass is more for scripting
so short names are not such an advantage, the opposite I would say. And
it's not pythonic at all, so it could confuse people with Python background.
The grass.script.*_command functions accept shortened option names
simply because they pass both the name and value straight to the
module. The Python code has no idea which options the module actually
accepts.
PyGRASS actually queries the module's interface via
--interface-description, so it knows the option names and their types.
Supporting abbreviations would require replicating the logic in
G_parser().
Now that this has been brought up, we might consider whether we need
to "un-abbreviate" some of the existing module options before GRASS 7
is finally released.
Replacing abbreviations shouldn't matter for command-line usage or
scripts using grass.script, but it will matter for PyGRASS, as scripts
are forced to use the exact option name.
--
Glynn Clements <glynn@gclements.plus.com>