Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Martin Landa
Hi,

2014-10-22 10:49 GMT+02:00 Martin Landa landa.mar...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Pietro
On Wed, Oct 22, 2014 at 10:49 AM, Martin Landa landa.mar...@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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Pietro
On Wed, Oct 22, 2014 at 11:12 AM, Martin Landa landa.mar...@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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Martin Landa
2014-10-22 17:36 GMT+02:00 Pietro peter.z...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Martin Landa
Hi,

2014-10-22 17:37 GMT+02:00 Pietro peter.z...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Pietro
On Wed, Oct 22, 2014 at 5:40 PM, Martin Landa landa.mar...@gmail.com wrote:
 2014-10-22 17:36 GMT+02:00 Pietro peter.z...@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.
:-D
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Pietro
On Wed, Oct 22, 2014 at 5:45 PM, Martin Landa landa.mar...@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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Martin Landa
Hi,

2014-10-22 18:09 GMT+02:00 Pietro peter.z...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Luca Delucchi
On 22 October 2014 18:10, Martin Landa landa.mar...@gmail.com wrote:
 Hi,


Hi,

 2014-10-22 18:09 GMT+02:00 Pietro peter.z...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Anna Petrášová
On Wed, Oct 22, 2014 at 11:40 AM, Martin Landa landa.mar...@gmail.com
wrote:

 2014-10-22 17:36 GMT+02:00 Pietro peter.z...@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

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] pygrass and shorten parameters

2014-10-22 Thread Glynn Clements

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 gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev