[Python-Dev] "as" keyword woes

Guido van Rossum guido at python.org
Sat Dec 6 21:29:09 CET 2008


On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano <warren 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.

Well, that's too bad, as 'as' is now a reserved word.

> Although there are other valid domain-specific uses for "as" as either a
> local variable or attribute names (e.g. systematic naming: as, bs, cs),
> those aren't nearly as important compared to "as" being available as the
> name of a generalized casting method -- one that is now strictly denied
> to users of Python 2.6 and 3.

If you had brought this up 5-10 years ago when we first introduced
'as' as a semi-keyword (in the import statement) we might have been
able to avert this disaster. As it was, nobody ever brought this up
AFICR, so I don't think it's *that* 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.

That's possible with sufficiently powerful parser technology, but
that's not how the Python parser (and most parsers, in my experience)
treat reserved words. Reserved words are reserved in all contexts,
regardless of whether ambiguity could arise. Otherwise *every*
reserved word would have to be allowed right after a '.', and many
keywords would have to be allowed as identifiers in other contexts.
That way lies PL/1...

Furthermore, how would you define the 'as' method? Would you also want
to be allowed to write

def as(self, target): ...

??? Trust me, it's a slippery slope, and you don't want to start going
down there.

> 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?

Don't bother writing a PEP to make 'as' available as an attribute
again. It has no chance of being accepted. Instead, think of a
different word you could use.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list