"as" keyword woes

Warren DeLano warren at delsci.com
Sat Dec 6 20:38:51 CET 2008

> Date: Fri, 05 Dec 2008 22:22:38 -0800
> From: Dennis Lee Bieber <wlfraed at ix.netcom.com>
> Subject: Re: "as" keyword woes
> To: python-list at python.org
> Message-ID: <bqadnTS6jM21h6fUnZ2dnUVZ_uydnZ2d at earthlink.com>
> 	I'm still in the dark as to what type of data could 
> even inspire the
> use of "as" as an object name... A collection of "a" objects? In which
> case, what are the "a"s? <G>

Please let me clarify.  It is not "as" as a standalone object that we
specifically miss in 2.6/3, but rather, the ability to use ".as" used as
a method or attribute name.  

In other words we have lost the ability to refer to "as" as the
generalized OOP-compliant/syntax-independent method name for casting:

new_object = old_object.as(class_hint)

# For example:

float_obj = int_obj.as("float")

# or 

float_obj = int_obj.as(float_class)

# as opposed to something like

float_obj = int_obj.asFloat()

# which requires a separate method for each cast, or

float_obj = (float)int_obj  

# which required syntax-dependent casting [language-based rather than

Of course, use of explicit casting syntax "(float)" is fine if you're
restricting yourself to Python and other languages which support
casting, but that solution is unavailable inside of a pure OOP
message-passing paradigm where object.method(argument) invocations are
all you have to work with.  

Please note that use of object.asClassname(...) is a ubiqitous
convention for casting objects to specific classes (seen in ObjectiveC,
Java, SmallTalk, etc.).  

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.

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.

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.

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?  


More information about the Python-list mailing list