[Guido van Rossum] > [...] One of the tasks is to adopt Greg Ward's options parsing module, > Optik. I propose to adopt this under the name "options". Any comments? My feeling is that Python should much avoid, for a library module, a name which is likely to be a user variable name. This would rule out "options". In my experience so far, the most irritating cases in Python hurding common words for itself have been `string' and `socket'. I know that some people write `s' for a string and would write `o' for options, but this algebraic style is not ideal. I find that using real words, like `counter', `ordinal', `cursor', `index' or such, yields more readable programs. When one "imports" a module, one has to give up using the module name for other purposes. Currently, I think _all_ my callable scripts which handle options already use `options' for a variable name, so I would prefer that `options' be left alone. This is why I think Python should not offer a module named "text" for example. As a principle for the future, let simple, common words be available to users for naming their own variables. -- François Pinard http://www.iro.umontreal.ca/~pinard
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4