"as" keyword woes

[Lie]

On Dec 7, 2:38 am, "Warren DeLano" <war... at delsci.com> wrote:
> > Date: Fri, 05 Dec 2008 22:22:38 -0800
> > From: Dennis Lee Bieber <wlfr... at ix.netcom.com>
> > Subject: Re: "as" keyword woes
> > To: python-l... at python.org
> > Message-ID: <bqadnTS6jM21h6fUnZ2dnUVZ_uydn... 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

And let things like:

filelike.print('lpt') # python 2.6
zipper.with('7z')
failure.try(alternative)
executecodeobject.if(True)
onfailure.break()

?