On Fri, Jul 23, 2010 at 8:22 PM, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
On Fri, Jul 23, 2010 at 3:31 PM, Gregory P. Smith <greg@krypto.org> 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.

Internationally yrs,

-- СJ

Where's the craigslist "best of" button for python-ideas posts when we need it? ;)