Warren DeLano wrote: > There, I assert that 'object.as(class_reference)' is the simplest and > most elegant generalization of this widely-used convention. Indeed, it > is the only obvious concise answer, if you are limited to using methods > for casting. How about "to"? Almost every language I have ever used uses "to" and not "as". Python predominately uses "to" already, so why would you fight that? And moreover, I have never seen a language or library that preferred "as", so I remain to be convinced that "as" is a good choice. > As someone somewhat knowledgable of how parsers work, I do not > understand why a method/attribute name "object_name.as(...)" must > necessarily conflict with a standalone keyword " as ". It seems to me > that it should be possible to unambiguously separate the two without > ambiguity or undue complication of the parser. It's not a matter of whether it is possible. It's a matter of simplicity and a lack of a worthy use-case for allowing it. In general, the trend has been to not allow any keywords as identifiers in the Python language. If there were such a worthy use-case, then what is really import is that it increases the complexity of /the language/ a human programmer needs to parse. > So, assuming I now wish to propose a corrective PEP to remedy this > situation for Python 3.1 and beyond, what is the best way to get started > on such a proposal? I think you will need to work on making a convincing argument as to why the keyword "as" is anymore special than say "for", or any other keywords for that matter. Unless you plan on proposing a reversal of the current keyword/identifier ideology, which is likely to be reject outright. -Scott -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu
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