On Fri, Jul 23, 2010 at 3:31 PM, Gregory P. Smith email@example.com wrote:
What next? An optional way to support case insensitive names using a unicode character prefix?
This suggests an innovative solution. Using the advanced phishing techniques of today’s bleeding edge Mafioso hackers, we can use unicode lookalikes to stand in for keywords. So, for example, the motivating use case is the desire to write elem.for. Well, all we need to do is use the Greek omicron and write elem.fοr. See the difference? No? Exactly!
This is a good first step as a workaround in older versions of Python, but I think we can do better than this in future version. Since it is so clearly useful and convenient with a wide variety of use cases to be able to use current keywords as variable names, I propose that we phase out the current set of keywords and replace them with vowel-shifted lookalikes: Cyrillic а for a, Cyrillic у for y, omicron for o, upside-down exclamation point for i, and the EU’s estimated sign ℮ for e. So, the current keywords:
and elif import return as else in try assert except is while break finally lambda with class for not yield continue from or def global pass del if raise
would be replaced with these new keywords:
аnd ℮l¡f ¡mpοrt r℮turn аs ℮ls℮ ¡n trу аss℮rt ℮xc℮pt ¡s wh¡l℮ br℮аk f¡nаllу lаmbdа w¡th clаss fοr nοt у¡℮ld cοnt¡nu℮ frοm οr d℮f glοbаl pаss d℮l ¡f rа¡s℮
Since this change is visually undetectable, I don’t see why we can’t just make it mandatory in 3.2 instead of going through the usual multi-release deprecation cycle. (I will admit that the transition might be quicker if someone could modify 2to3 and make 3_1to3_2 to help people convert their legacy scripts.)
Can we get fast-track BDFL approval on this one? Seems like a slam dunk to me.