Re: [Python-ideas] [Python-Dev] Set the namespace free!
On Thu, Jul 22, 2010 at 9:24 AM, <gregory.smith3@sympatico.ca> wrote:
I agree with the idea, but a far less radical change is needed to get the desired result. The basic idea is this: it should be possible to use any name as an identifier in the syntax, including names like 'while' and 'import'. But there is no need to mess up the entire language to allow this (either by quoting all the identifiers, perl-style, or by marking the keywords).
Yuck. Anyone who feels they need a variable named the same a reserved word simply feels wrong and needs reeducation. New words are introduced very rarely and we do care about the ramifications when we do it. What next? An optional way to support case insensitive names using a unicode character prefix? -gps
All that is needed is something like this:
foo = 7 :foo = 7 # exactly like foo=7 :while= 3 # assigns 3 to variable 'while' globals()['while']=3 # current way to do this
print element.:for # from example below # # keyword parameters to a function call: # BuildUrlQuery( lang='en', item='monsoon', :class='normal') # -> "?lang=en&query=monsoon&class=normal"
The generic keyword function call is a really nice language feature, but it's rather impaired by the need to avoid those names which happen to be keywords.
The lack of this is most painful when you are auto-generating python code which forms a bridge to another language with its own namespace (as in XML example). It's a pain when some of the names you might generate could conflict with python keywords. So, you end up using dicts and getattrs for everything and the code gets much less readable. With a simple escape like :name available, it's worthwhile to do everything with identifiers and generate the escape only as needed for these.
One of the great strengths of python is the ability to form cleans and comprehensive bridges to other languages and environments (thus, in many cases, avoiding the need to write programs in those other environments :-) ). This feature would fill a gap there.
The python tcl/tk interface is a bit messed up since tcl/tk uses some names for options which conflict with python keywords, and so you need to add '_' to those names.
There is a feature like this in VHDL: \name\ and \while\ are identifiers, the backslashes are not part of the name, but just quote it. In VHDL you can write identifiers like \22\, and \!This?is=Strange\ as well; since VHDL creates modules that have named ports, and those modules can interface to things generated by other environments, they needed a way to assign any name to a port.
For python, I'm not sure it makes sense to allow identifiers that doesn't follow the basic rule "[A-Za-z_][A-Za-z_0-9]*" -- that could break some debugging tools which expect variable names to be well-formed -- but it would be useful to be able to use any well-formed name as an identifier, including those which happen to be keywords.
I've suggested :name, which doesn't break old code, and doesn't require using any new punctuation. Syntax would not change, just the lexical definition of 'identifier'. If the intent is to allow arbitrary names (not just well-formed ones), then n'name' would work better (and is consistent with existing stuff).
Date: Thu, 22 Jul 2010 10:41:39 -0400 From: jnoller@gmail.com To: bartosz-tarnowski@zlotniki.pl CC: python-dev@python.org Subject: Re: [Python-Dev] Set the namespace free!
On Thu, Jul 22, 2010 at 10:04 AM, Bartosz Tarnowski <bartosz-tarnowski@zlotniki.pl> wrote:
Hello, guys.
Python has more and more reserved words over time. It becomes quite annoying, since you can not use variables and attributes of such names. Suppose I want to make an XML parser that reads a document and returns
an
object with attributes corresponding to XML element attributes:
elem = parse_xml("<element param='boo'/>") print elem.param boo
What should I do then, when the attribute is a reserver word? I could use trailing underscore, but this is quite ugly and introduces ambiguity.
elem = parse_xml("<element for='each'/>") print elem.for_ #????? elem = parse_xml("<element for_='each'/>") print elem.for__ #?????
My proposal: let's make a syntax change.
Let all reserved words be preceded with some symbol, i.e. "!" (exclamation mark). This goes also for standard library global identifiers.
!for boo in foo: !if boo is !None: !print(hoo) !else: !return !sorted(woo)
This would allow the user to declare any identifier with any name:
for = with(return) + try
What do you think of it? It is a major change, but I think Python needs it.
-- haael
I'm not a fan of this - I'd much prefer[1] that we use the exclamation point to determine scope:
foobar - local !foobar - one up !!foobar - higher than the last one !!!foobar - even higher in scope
We could do the inverse as well; if you append ! you can push variable down in scope.
Jesse
[1] I am not serious. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gsmith%40alumni.uwaterloo....
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
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
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,
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. :-) -- Greg
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 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? ;) -gps
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.
Yuck. Anyone who feels they need a variable named the same a reserved word simply feels wrong and needs reeducation.
I hope you meant to apply that yuck to :for or !try as variable names and if so I agree. On the other hand a convention that class_="x" puts "&class=x" in the URL seems quite reasonable. --- Bruce (via android)
participants (7)
-
Bruce Leban -
Carl M. Johnson -
Eric Smith -
Greg Ewing -
Gregory P. Smith -
MRAB -
Nick Coghlan