[GRASS-dev] significant change in g.parser behavior for GRASS 7

[Michael Barton]

The issue is not about whether upper or lower case (or other characters) are good programming form or not in on language or another. This varies from context to context.

The issue is about a change in behavior of how GRASS scripts and modules are parsed between GRASS 6 and 7 that can cause unforseen problems for users when their scripts no longer run. I'm not convinced that aesthetics alone is a reason to break existing scripts that people may have written. There may well be other reasons. But if it is only aesthetics or is an unintended byproduct of some other change, we should consider fixing it.

Personally, I'd prefer that g.parser treats upper and lower case characters as equivalent in options (e.g., Kt = KT = kt = kT). That would avoid the possibility of confusion from having different options for Kt and kT, while not throwing an error if the user typed "kt" in any combination of case. Although there are common programming forms in Python, for example, it does not generate an error if upper or lower case is used.

At the very least, GRASS 7 should generate an error that says "upper case characters are not allowed in options names in GRASS 7". The current error message, "<Abc=1> is not a valid option", is ambiguous and misleading, as it suggests that the *value* is somehow incorrect or being parsed incorrectly.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



On Sep 24, 2014, at 7:34 PM, Vaclav Petras <wenzeslaus at gmail.com<mailto:wenzeslaus at gmail.com>> wrote:



On Wed, Sep 24, 2014 at 7:53 PM, Michael Barton <Michael.Barton at asu.edu<mailto:Michael.Barton at asu.edu>> wrote:
I just learned that using upper case characters for a GRASS 7 module option means that g.parser will not recognize it. That is for module. “r.foo" with options “Abc” and “def”, the command

r.foo Abc=1 def=2

will return an error <Abd=1> is not a valid option.

GRASS 6 does not produce an error in this case. The module will run fine.

This breaks all kinds of existing scripts from GRASS6, as well as scripts that are designed to be chained together. I’ve never seen any discussion of this. Perhaps I missed it because I was in the field or something. Is there a reason for this significant change of g.parser behavior?


I think that the lowercase options are a good choice. There are some advantages of allowing uppercase like names of some coefficients (you can have phi but also Phi, k and K) and abbreviation (HTML, PDF). However, I think that the disadvantages are bigger. According to what I have seen, with possibility to have both options (upper and lower case), people would create options slope, but some other Slope, some perhaps even SLOPE. With two words in the option name, it would be even worse: elevation_model, ElevationModel, Elevation_model, Elevation_Model, ...

The consistency is not the only reason, we have there also Python and Bash scripts. In Python, the option names are function parameters which in the most Python coding styles should be lowercase (with or without underscores) which is exactly what GRASS 7 parser wants. For Bash the situation is different, we uppercase all the options (I believe in both 6 and 7) because they are part of variable names, so of course we can do this only if we know that all the letters have the same case, in 7 we know, they are lowercase.

I don't think that occasional need for uppercase letters outweighs the potential issues which would be potentially encountered by everyone.

Unfortunately, I'm not sure where is this documented and what was the reason when it was introduced, from the logs it seems that the behavior was introduced 6 year ago by Glynn:

http://trac.osgeo.org/grass/changeset/32261

I don't see any other place where the relevant check is done, so I think it is this change. The check should be actually done when creating an option, not when the option has a value (now it look like as an user error rather then programmer's error).

Glynn, can you please comment on it?

Vaclav


Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262<tel:480-965-6262> (SHESC), 480-965-8130<tel:480-965-8130>/727-9746 (CSDC)
fax: 480-965-7671<tel:480-965-7671> (SHESC),  480-727-0709<tel:480-727-0709> (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu<http://csdc.asu.edu/>
















_______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140925/b5195e65/attachment.html>