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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
