#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev