<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>