[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 hcho):

 Replying to [comment:80 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.
 >

 I strongly agree with you. Personally, I'm fine with the old type names.
 If shortening rast3d= is an issue because of conflicts with rast=, we
 could change it to volume= or voxel= (and vo.* module names). I don't
 think it's a good idea to have to type an underscore before certain option
 names in Python or possibly other languages and we could avoid such
 annoying/inconsistent situations by naming elements more carefully.

 > 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.

 +1

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