Carl M. Johnson 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℮

Instead of "¡" use "і" ("\u0456") and instead of "℮" use "е" ("\u0435").

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,

On Sun, Jul 25, 2010 at 11:08 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

...

Carl M. Johnson wrote:

...

...

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

If you saw the funky way those all appear to me in Thunderbird, you wouldn't have written that sentence. :-)

That's the case for me with Gmail-in-Firefox, but with MRAB's substitutions it becomes genuinely indistinguishable: а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е Fonts with incomplete glyph sets will still look wrong, of course. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 7/23/10 11:22 PM, Carl M. Johnson 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

CJ for the win! Bravo. -- Eric.

Carl M. Johnson 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℮

Instead of "¡" use "і" ("\u0456") and instead of "℮" use "е" ("\u0435").

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,

On Sun, Jul 25, 2010 at 11:08 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

...

Carl M. Johnson wrote:

...

...

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

If you saw the funky way those all appear to me in Thunderbird, you wouldn't have written that sentence. :-)

That's the case for me with Gmail-in-Firefox, but with MRAB's substitutions it becomes genuinely indistinguishable: а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е Fonts with incomplete glyph sets will still look wrong, of course. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 7/23/10 11:22 PM, Carl M. Johnson 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

CJ for the win! Bravo. -- Eric.