On Dec 7, 2:38 am, "Warren DeLano" <[EMAIL PROTECTED]> wrote: > > Date: Fri, 05 Dec 2008 22:22:38 -0800 > > From: Dennis Lee Bieber <[EMAIL PROTECTED]> > > Subject: Re: "as" keyword woes > > To: [EMAIL PROTECTED] > > Message-ID: <[EMAIL PROTECTED]> > > > 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() ? -- http://mail.python.org/mailman/listinfo/python-list