[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
 Reporter:  martinl               |       Owner:  grass-dev@…              
     Type:  task                  |      Status:  new                      
 Priority:  blocker               |   Milestone:  7.0.0                    
Component:  Default               |     Version:  unspecified              
 Keywords:  standardized options  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by wenzeslaus):

 Replying to [comment:79 glynn]:
 > Replying to [comment:77 annakrat]:
 > > Replying to [comment:76 cmbarton]:
 > > > Could it cause a problem somewhere down the line to have this term
 beginning with a number--e.g. If it is used to name a temp file or
 something?
 > >
 > > As I already said, it causes problems for Python because keyword
 parameter can't start with number. This is solvable by adding underscore
 and some special handling of this case, which is partially there already.
 It violates pep8.
 >
 > PEP8 is a style guide. There is no inherent reason why an argument name
 cannot start with an underscore. And we're not even talking about explicit
 arguments; such arguments will only ever be obtained via the **kwargs
 mechanism.

 The problem may come once you want to use parameter as an variable or
 member variable. In later case underscore would means private which is
 technique not limited to Python. I'm also afraid that this can hit us or
 somebody else in some other language or system. Almost nothing allows
 numbers at the beginning of identifiers. I also think that for 3D raster
 it is much more probable that you hit this issue. For example, how should
 I name variable in my script which holds 3D raster map name or its
 maximum? `_3draster_name`? `_3draster_max`? I can of course name my
 variables whatever I want but wouldn't we stick to `rast3d` or `raster3d`
 in the GRASS source code anyway?

 >
 > In fact, I think that this is why I chose to use a leading underscore
 rather than a trailing underscore.
 >
 > Still, I'd rather avoid having option names start with a digit. But
 unless we relax the ambiguity check, it wouldn't outweigh my preference to
 avoid using an option name which has a very common option name (rast or
 raster) as a prefix.

 I'm glad you are saying that. I think it is really important to state the
 priorities and motivations. If we just want backwards compatibility, then
 some special check in the parser can handle old short option names. And if
 we value the most backwards compatibility and short options, we probably
 should not not shorten at all in these special cases (type names).

 Perhaps it is useful to ask why we want short options. It is for manual
 typing? Well then we perhaps should use techniques used elsewhere. And we
 are actually partially doing it. There is IDE-like auto-complete in GUI,
 Python dir completed is implemented for PyGRASS module interface and of
 course Linux command line auto-completes module names. So why not to take
 it further and auto-complete also parameters and perhaps other things by
 implementing auto-complete for shell?

 Classic unix-like command line is anyway the only place where short
 options really matter if you consider the things above and also that you
 should not use shortened option names in scripts because it is not
 readable (that's why we are unabbreviating them, right?).

 Perhaps we don't have to unabbreviate everything. It seems to me that
 there is no will to unabbreviate options for `g.region` or module names
 containing rast, vect or rast3d. I'm for explicit long descriptive option
 names but if it creates more issues then it solves (`3draster`) and if
 everybody would be using the shortened version all the time anyway
 (`rast`, ...), I prefer not to change them.

 If we want short options for whatever reason, let's standardize them,
 rather than standardize the long options and provide ways how to avoid the
 standard.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:80>
GRASS GIS <http://grass.osgeo.org>