[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