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