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

 I full agree with Vaclav.

 However, the modification of GRASS was already performed, regardless the
 fact that we still discuss the renaming of rast, rast3d and vect options.

 This, as i already stated before, completely broke the temporal framework.
 It is not only a matter of renaming option names, the whole internal
 temporal data type system and handling of different map types was broken
 because of this. What to do now with temporal module names? Must t.rast.*
 modules be renamed into t.raster.*? Or t.rast3d.* modules into
 t.3draster.*?

 Someone tried to fix the framework by simply renaming rast3d into
 3draster, but this did not solved the problem. The framework was still
 broken. Why was the testsuite not used to check these changes? Why do we
 have the test-framework anyway?
 Just a tiny hint: renaming the option "n" from v.random into "npoints"
 broke plenty of temporal vector module tests, since they are using PyGRASS
 to call v.random and PyGRASS can't handle abbreviations.

 I needed 5 hours to fix the temporal framework and i am pretty sure that i
 did not catch all issues that were introduced with the renaming.

 Putting GRASS in such broken a state without using the testuite to write
 and use tests or at least to verify the changes with existing tests is
 IMHO irresponsible. Especially if we plan to make a beta release.

 I am sorry for my harsh words, but i had to invest 5h for no good reason
 to keep on with my regular work.


 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.
 >
 > 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:85>
GRASS GIS <http://grass.osgeo.org>