Date: Fri, 05 Dec 2008 22:22:38 -0800 From: Dennis Lee Bieber Subject: Re: "as" keyword woes To: python-list@python.org Message-ID:

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