"as" keyword woes

[Warren DeLano]

> 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
object-based].

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?  

Cheers,
Warren