"as" keyword woes

Carl Banks pavlovevidence at gmail.com
Sat Dec 6 21:13:16 CET 2008


On Dec 6, 1:38 pm, "Warren DeLano" <war... at delsci.com> 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.

I don't agree with your assertion.

object.as_type(class_reference)
object.cast(class_reference)

These are both concise and obvious.


> 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 possible, and they've been doing it for years, and they could
have continued doing it if they wanted to.

You'll notice that nowhere the Python grammar can two identifiers be
separated by whitespace.  So if you have two identifiers separated by
whitespace, and the second one is "as", you know it has to be keyword
"as".

Well, they made it a keyword anyway.  It was never a question of
whether they could do it.


> 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'd be wasting your time, but the general procedure is
outlined in PEP 1.

Basically, you write a pre-PEP (aka PEP XXX) according to the
guidelines in PEP 1, which you would post here and request comments on
it.  Then, if you can muster some support for it, you would send it to
PEP maintainer (the email is listed somewhere on the PEPs page, dig
for it), and get a number assigned, upon which time Guido van Rossum
will read it and any comments in python-dev, and make a pronouncement
of some sort.

If you write a PEP, I advise you to try to sound less whiny and than
you have in this thread.  Saying "object.as(class_reference) is highly
convenient because it mirrors textually the Java convention of
object.asFloat" will go over a lot better than "object.as
(class_reference) is the only obvious concise answer".


Carl Banks



More information about the Python-list mailing list