Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Op 2005-08-16, Peter Hansen schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Why has one made a difference in search policy for finding a variable based on whether the variable is rebound or not in the first place. Do you really not understand the reason, or do you simply disagree with it? How can I understand something that was never explained to me. Each time I saw this coming up people answered the technical question about the difference between rebinding and accessing or modification. I haven't seen anyone answer the question asnwer at this level. It's a choice with rational thought behind it. Then please explain this rational thought instead of just asserting that it is present. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Op 2005-08-06, Mike Meyer schreef [EMAIL PROTECTED]: John Roth [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A much better idea would be to fix the underlying situation that makes the global statement necessary. You can't fix this. This code (in some python-like langauge that isn't python): x = 23 def fun(): x = 25 # Rest of code has two possible interpretations. Either the occurrence of x in fun references the global, or it references a local that shadows the global. There are reasons for wanting both behaviors. So you have to have some way to distinguish between the two, and you want it to happen per variable, not per function. The method with the fewest keywords is to have one be the default, and some keyword that triggers the other. So the only way to remove the global statement would be to have some way to mark the other interpretation, with say a local decleration. I thik that would be much worse than global. For one thing, most variables would be local whether or not they are declared. Second, having an indication that you need to check module globals in the function is a better than not having that clue there. I disagree here. The problem with global, at least how it is implemented in python, is that you only have access to module scope and not to intermediate scopes. I also think there is another possibility. Use a symbol to mark the previous scope. e.g. x would be the variable in local scope. @.x would be the variable one scope up. @[EMAIL PROTECTED] would be the variable two scopes up etc. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Op 2005-08-06, Peter Hansen schreef [EMAIL PROTECTED]: Paolino wrote: [EMAIL PROTECTED] wrote: def enclosing(): var=[] var[0]=2 def enclosed(): var[0]=4 which is like saying python is not working It's ok to mark non locals,but why var=4 is not searched outside and var[0]=4 yes? Because var=4 rebinds the name var, while var[0]=4 does not. It's exactly the same issue with using global, where you don't need it if you aren't rebinding the name. This doesn't answer the question at the appropiate level IMO. Why has one made a difference in search policy for finding a variable based on whether the variable is rebound or not in the first place. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Antoon Pardon wrote: Why has one made a difference in search policy for finding a variable based on whether the variable is rebound or not in the first place. Do you really not understand the reason, or do you simply disagree with it? It's a choice with rational thought behind it. Whether it's the best choice is a matter of opinion. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
On 5 Aug 2005 21:22:41 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm not saying 'modulescope' and 'module' are the only alternatives or even the best anyone can come up with. 'global' has the connotation of being visible *EVERYWHERE* where in Python it is just visible in one module's space. One way is to spell this with a dotted name (e.g., shared or SHARED_GLOBALS) and use a module dedicated for this purpose, e.g., import SHARED_GLOBALS def foo(): SHARED_GLOBALS.x = 'shared x may be (re)bound from anywhere' Can you think of a better alternative or do you believe 'global' is the best possible? I don't think 'global' would be best if we were starting out with the name spaces we have now, but as you know it effectively means 'modulescope' and derives from a time where that was the only unqualified alternative to local. There's been a lot of discussion about this, periodically ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
On Sat, 06 Aug 2005 20:56:13 GMT, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Sat, 06 Aug 2005 21:16:13 +0200, Paolino [EMAIL PROTECTED] declaimed the following in comp.lang.python: The point is not to understand obvious technical things, but having a coherent programming framework.If I can modify an out of scope object Seems coherent to me: a) names /BIND/ locally unless declared global (at which point they bind within the file) b) name /lookup/ is local first, then global c) conflict occurs when a name lookup potentially could find a global [clause b: name not found in local space, found in global], but later in the same function that same name is bound locally [clause a: no global declaration was seen so binding is to a local]. However, the static language parse will have flagged the name as reserved for a local, and then complains because one is attempting to use a local before it has been bound to a value. If you aren't changing the binding of the name, you don't need to worry about global And, in Python, this concept of BINDING is a core language feature -- it is NOT something compatible to other languages, and removing it will mean creating a new language that is NOT Python. In other languages, a name is a synonym for a memory address (call it a box), and it will always be the same box. Assignment copies box contents from source to destination box. In Python, a name is a movable label that is stuck to a box, and the name can be moved to other boxes. Assignment in Python moves the label from the destination (the old box) TO the source box -- the source box now has multiple labels (names) bound to it. Both names refer to the same box. var[i] is a two step process: first find the box with the label var, THEN open the box and find the i'th item /in/ the box... You can change the item /in/ the box without changing the label on the box. I find the above label/box metaphor a bit misleading, because the box surfaces where labels may be stuck are name spaces, and IMO are more like cork bulletin boards than the containers suggested by box (although admittedly a bulletin board could be viewed as a kind of container for labels ;-) I prefer the name-tags-with-strings metaphor, where name tags may be pinned on any namespace/bulletin board and the strings from tags on many different bulletin boards may be tied to (bound) the same object. But to carry this a little further, name tags aren't really the only things that have strings that lead to objects. Name tags's strings are accessed via name space objects' lookup mechanisms, which we program with various name lookup syntax, but other objects can also have strings leading to objects, e.g. lists, where you retrieve a string originating from the nth string-tying-point instead of finding a string-tying-point by name amongst a bunch of labels pinned to a bulletin board. IOW, ...open the box and find the i'th item /in/ the box... is not really finding the i'th item _itself_ /in/ the box. It is finding one end of a string tied to some point /in/ the box, but the actual item/object is at the other end of the string, not /in/ the box, and many other strings may potentially also be leading to the same object, whether originating from anonymous structural binding points in other objects, or named binding points in name-tag-containing objects/namespaces. Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Antoon Pardon wrote: I disagree here. The problem with global, at least how it is implemented in python, is that you only have access to module scope and not to intermediate scopes. I also think there is another possibility. Use a symbol to mark the previous scope. e.g. x would be the variable in local scope. @.x would be the variable one scope up. @[EMAIL PROTECTED] would be the variable two scopes up etc. Looks like what you want is easier introspection and the ability to get the parent scope from it in a simple way. Maybe something like a builtin '__self__' name that contains the information, then a possible short 'sugar' method to access it. '__self__.__parent__', would become @ in your example and '__self__.__perent__.__self__.__parent__' could become @[EMAIL PROTECTED] Somthing other than '@' would be better I think. A bare leading '.' is another possiblity. Then '..x' would be the x two scopes up. This isn't the same as globals. Globals work the way they do because if they weren't automatically visible to all objects in a module you wouldn't be able to access any builtin functions or class's without declaring them as global (or importing them) in every function or class that uses them. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
[EMAIL PROTECTED] wrote: I've heard 2 people complain that word 'global' is confusing. Perhaps 'modulescope' or 'module' would be better? Am I the first peope to have thought of this and suggested it? Is this a candidate for Python 3000 yet? Chris After reading though some of the suggestions in this thread, (but not all of them), how about something a bit more flexible but not too different. For python 3000 if at all... Have the ability to define names as shared that only live while the function that declared them has not exited. The new statements could be called *share* and *shared*. def boo(): shared x,y,z # Used names predefined in shared name space. return x+1,y+2,z+3 def foo(): x,y,z = 1,2,3 share x,y,z # These would be visible to sub functions # but not visible to parent scopes once the # function ends. [*1] boo() # modify shared x,y and z in foo. [*1.] Unless they have also declared the same names as share. (See below.) 'Share' is used to define names to be visible in child scopes, and 'shared' allows access to shared names declared in parent scopes. Having too keywords is more explicit, although this may work with a single key word pretty much as it does now. A single shared name space would still be used where 'share' adds names to be 'shared' and those names are deleted when the function that declared them exits. They don't need to live past the life of the function they were first declared in. In recursive functions, (or when a name is reshared), declaring a name as shared could just increment a reference counter, and it wouldn't be removed from shared until it reaches zero again. Using 'share' twice with the same name in the same function should cause an error. Using 'shared' with a name that is not in shared name space would cause an error. Just a few thoughts. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
[EMAIL PROTECTED] wrote: I've heard 2 people complain that word 'global' is confusing. Perhaps 'modulescope' or 'module' would be better? Am I the first peope to have thought of this and suggested it? Is this a candidate for Python 3000 yet? Chris I don't think the global keyword is useful actually. What's so special in a module nemespace to be priviledged like that. The point IMO is accessing names defined somewhere in the enclosing namespaces. def enclosing(): var=2 def enclosed(): outer var=4 this is the base of something useful. as it is now you neeed def enclosing(): class Var:_=2 def enclosed(): Var._=4 or like others suggested def enclosing(): var=[] var[0]=2 def enclosed(): var[0]=4 which is like saying python is not working It's ok to mark non locals,but why var=4 is not searched outside and var[0]=4 yes? I think there is only one or none possible solution to an 'outer' statement which is the first bound name matching the 'outer' vars name in the chain of enclosing namespaces. Why every instance doesn't point to its namespace and every namespace to its namespace? Unpythonic ? Illogicities to my eyes or at least non-linerities that makes 'global' an interesting strangeness to talk about. And that namespaces should start being easy sooner or later. Regards Paolino ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Paolino wrote: [EMAIL PROTECTED] wrote: def enclosing(): var=[] var[0]=2 def enclosed(): var[0]=4 which is like saying python is not working It's ok to mark non locals,but why var=4 is not searched outside and var[0]=4 yes? Because var=4 rebinds the name var, while var[0]=4 does not. It's exactly the same issue with using global, where you don't need it if you aren't rebinding the name. (Those who don't understand the difference between rebinding a name and modifying an object will need to figure out that distinction before they can participate much in a discussion about Python scopes, I think.) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Peter Hansen wrote: Paolino wrote: [EMAIL PROTECTED] wrote: def enclosing(): var=[] var[0]=2 def enclosed(): var[0]=4 which is like saying python is not working It's ok to mark non locals,but why var=4 is not searched outside and var[0]=4 yes? Because var=4 rebinds the name var, while var[0]=4 does not. It's exactly the same issue with using global, where you don't need it if you aren't rebinding the name. (Those who don't understand the difference between rebinding a name and modifying an object will need to figure out that distinction before they can participate much in a discussion about Python scopes, I think.) The point is not to understand obvious technical things, but having a coherent programming framework.If I can modify an out of scope object (ie var list) without saying it's an 'outer' no problem as python looks for it, in fact I should put 'outer' to rebind var to 4 if I refer to 'var' as an outer binding, python can find it if it exists, if it doesn't it can raise an error. Many other ways to identify the scope layer of a binding can be thought about:having only 'global' and pretending that is the only useful namspace layer to be identify for changing its bindings is just a piece of sense. Paolino ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
[EMAIL PROTECTED] wrote: I'm not saying 'modulescope' and 'module' are the only alternatives or even the best anyone can come up with. 'global' has the connotation of being visible *EVERYWHERE* where in Python it is just visible in one module's space. Can you think of a better alternative or do you believe 'global' is the best possible? When designing a language meant to be easy to use as well as powerful feature-wise, you have to weighh between things like technical accuracy of a term (which you are focusing on), how much typing it takes, how easy it is to remember and spell correctly, and how the term is commonly understood and used. Sometimes python takes one of those considerations to the extreme (like def) or has a uncommon view of common understanding (like lambda). But global is the best term I can think of for the way it is used, and it is by far the most common term used for these kind of variables in numerous other languages including vb, php, ruby, etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Mike Meyer [EMAIL PROTECTED] writes: You can't fix this. This code (in some python-like langauge that isn't python): x = 23 def fun(): x = 25 # Rest of code has two possible interpretations. The fix is to add a local declaration in fun: local x = 25 for example. If you want the one from the outer scope, then use, perhaps, outer x = 25 One really screwy situation with Python is x = 23 def f(): x = 25 def g(): x += 3 g obviously is supposed to inherit x from the surrounding scope, but there's no way for g to actually change x. -- http://mail.python.org/mailman/listinfo/python-list
Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
I've heard 2 people complain that word 'global' is confusing. Perhaps 'modulescope' or 'module' would be better? Am I the first peope to have thought of this and suggested it? Is this a candidate for Python 3000 yet? Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
[EMAIL PROTECTED] wrote: I've heard 2 people complain that word 'global' is confusing. Perhaps 'modulescope' or 'module' would be better? Am I the first peope to have thought of this and suggested it? Is this a candidate for Python 3000 yet? It is likely that more people would find module or modulescope confusing. Plus module has a different customary meaning already: import module -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
I think D H is right. Or even if you'd find out that most of the people would better like 'modulescope' or 'module', (what is, i think, imposible), you'd destroy the backward-compatibility with older versions of Puthon if you implement it. But it won't be implemented. Trust me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've heard 2 people complain that word 'global' is confusing. Perhaps 'modulescope' or 'module' would be better? Am I the first peope to have thought of this and suggested it? Is this a candidate for Python 3000 yet? Chris A much better idea would be to fix the underlying situation that makes the global statement necessary. I doubt if this is going to happen either, though. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Python 3000 is not worried about backward compatibility. It is worried more about what is *best* and getting it done. Trust me. Let me ask an academic questionIs 'global' the *best* choice of all choices in Webster's dictionary? If it is then I'll give up and go home. If not then well. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
Your solution is the best of them all. However, I don't have the foggiest idea how it would be accomplished. Are you *sure* you can change design so that there is no need for a keyword like 'global'? Please enlighten me. I'd really appreciate it. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
John Roth [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A much better idea would be to fix the underlying situation that makes the global statement necessary. You can't fix this. This code (in some python-like langauge that isn't python): x = 23 def fun(): x = 25 # Rest of code has two possible interpretations. Either the occurrence of x in fun references the global, or it references a local that shadows the global. There are reasons for wanting both behaviors. So you have to have some way to distinguish between the two, and you want it to happen per variable, not per function. The method with the fewest keywords is to have one be the default, and some keyword that triggers the other. So the only way to remove the global statement would be to have some way to mark the other interpretation, with say a local decleration. I thik that would be much worse than global. For one thing, most variables would be local whether or not they are declared. Second, having an indication that you need to check module globals in the function is a better than not having that clue there. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)
[EMAIL PROTECTED] wrote: I've heard 2 people complain that word 'global' is confusing. Perhaps 'modulescope' or 'module' would be better? Am I the first peope to have thought of this and suggested it? Is this a candidate for Python 3000 yet? Chris Hmm.. instead of 'global', how about 'outside' ? It seems a bit more intuitive to me because it suggests that you mean, the variable defined outside this scope or outside any nestedness. But then again it could be confused to mean just one scope above this one which isn't necessarily module scope (nested functions, etc.)... still, might be less confusing than 'global'. Another alternative to having to say global var would be to use some sort of indicator that you want the global with each usage, like, global.var or outside.var -- http://mail.python.org/mailman/listinfo/python-list
