[GRASS-dev] pygrass and shorten parameters

[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 <glynn at gclements.plus.com>