Warren DeLano wrote:

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.

How about "to"? Almost every language I have ever used uses "to" and not "as". Python predominately uses "to" already, so why would you fight that? And moreover, I have never seen a language or library that preferred "as", so I remain to be convinced that "as" is a good choice.

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.

It's not a matter of whether it is possible. It's a matter of simplicity and a lack of a worthy use-case for allowing it. In general, the trend has been to not allow any keywords as identifiers in the Python language. If there were such a worthy use-case, then what is really import is that it increases the complexity of /the language/ a human programmer needs to parse.

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?

I think you will need to work on making a convincing argument as to why the keyword "as" is anymore special than say "for", or any other keywords for that matter. Unless you plan on proposing a reversal of the current keyword/identifier ideology, which is likely to be reject outright.

-Scott

On 06 Dec 2008, at 20:38, Warren DeLano wrote:

...

Date: Fri, 05 Dec 2008 22:22:38 -0800 From: Dennis Lee Bieber wlfraed@ix.netcom.com Subject: Re: "as" keyword woes To: python-list@python.org Message-ID: bqadnTS6jM21h6fUnZ2dnUVZ_uydnZ2d@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

As long as "as" is widely known as a keyword, I don't see the problem. Every python developer knows that the convention is to add a trailing underscore when you want to use a reserved word in your code. Besides, your examples are quite abstract. I'm sure it's possible to find good examples for "while", "with", "import", "from" (I often use "from_") or "try" as well. Or perhaps that the python keywords should be "as_" so we leave "as" free for eventual methods?

As for the implicit proposition of allowing keywords only for methods, I agree with Guido about it being a slippery slope. So we would end up with a language where it is allowed to name methods after keywords, but not functions (they can be declared in the local scope)? Yikes! Oh well, maybe it's possible for an intelligent parser to distinguish between keywords and function references, but think of the poor grammar highlighters in all source editors! What a nightmare it will be for them. Anyway, is there any language that does this, allowing keywords as method names? I don't know, but if not, there's probably a reason for it.

Your views on code elegance are also rather Javaish. I'd go for "class_reference(object)" (and why the heck would you "be limited to using method for casting"?).

Ciao, Virgil