[Python-Dev] "as" keyword woes
Scott Dial
scott+python-dev at scottdial.com
Sat Dec 6 21:06:42 CET 2008
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
More information about the Python-Dev
mailing list