#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 glynn): Replying to [comment:81 hcho]: > 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. There are two reasons why an option name cannot be used in Python. One is if it doesn't conform to the syntax for an identifier (e.g. starts with a digit). The other is if it is a reserved word (e.g. "from"). Avoiding the first case is simple enough. A requirement that option names begin with a letter and consist solely of letters, digits and underscores will ensure conformance with the identifier syntax for any common language. The second one is more awkward, as different languages have different sets of reserved words. The only real constant is that many of them are quite common words which would frequently be an ideal choice for an option name. I'm not sure that we should reject such names simply because they can't be used as a variable/parameter/etc name in a specific language without a tweak such as adding an underscore (or changing case; now that option names are limited to lower-case, having grass.script.make_command() force each name to lower case would be feasible). -- Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:83> GRASS GIS <http://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev