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