Re: [Python-Dev] Early PEP draft (For Python 3000?)
On 10/16/05, Josiah Carlson <jcarlson@uci.edu> wrote:
Calvin Spealman <ironfroggy@gmail.com> wrote:
On 10/14/05, Josiah Carlson <jcarlson@uci.edu> wrote:
Calvin Spealman <ironfroggy@gmail.com> wrote:
On 10/11/05, Eyal Lotem <eyal.lotem@gmail.com> wrote:
locals()['x'] = 1 # Quietly fails! Replaced by: frame.x = 1 # Raises error
What about the possibility of making this hypothetic frame object an indexable, such that frame[0] is the current scope, frame[1] is the calling scope, etc.? On the same lines, what about closure[0] for the current frame, while closure[1] resolves to the closure the function was defined in? These would ensure that you could reliably access any namespace you would need, without nasty stack tricks and such, and would make working around some of the limitation of the closures, when you have such a need. One might even consider a __resolve__ to be defined in any namespace, allowing all the namespace resolution rules to be overridden by code at any level.
-1000 If you want a namespace, create one and pass it around. If the writer of a function or method wanted you monkeying around with a namespace, they would have given you one to work with.
If they want you monkeying around with their namespace or not, you can do so with various tricks introspecting the frame stack and other internals. I was merely suggesting this as something more standardized, perhaps across the various Python implementations. It would also provide a single point of restriction when you want to disable such things.
What I'm saying is that whether or not you can modify the contents of stack frames via tricks, you shouldn't. Why? Because as I said, if the writer wanted you to be hacking around with a namespace, they should have passed you a shared namespace.
From what I understand, there are very few (good) reasons why a user should muck with stack frames, among them because it is quite convenient to write custom traceback printers (like web CGI, etc.), and if one is tricky, limit the callers of a function/method to those "allowable". There may be other good reasons, but until you offer a use-case that is compelling for reasons why it should be easier to access and/or modify the contents of stack frames, I'm going to remain at -1000.
I think I was wording this badly. I meant to suggest this as a way to define nested functions (or classes?) and probably access names from various levels of scope. In this way, a nested function would be able to say "bind the name 'a' in the namespace in which I am defined to this object", thus offering more fine grained approached than the current global keyword. I know there has been talk of this issue before, but I don't know if it works with or against anything said for this previously.
Calvin Spealman <ironfroggy@gmail.com> wrote:
On 10/16/05, Josiah Carlson <jcarlson@uci.edu> wrote: [snip]
What I'm saying is that whether or not you can modify the contents of stack frames via tricks, you shouldn't. Why? Because as I said, if the writer wanted you to be hacking around with a namespace, they should have passed you a shared namespace.
From what I understand, there are very few (good) reasons why a user should muck with stack frames, among them because it is quite convenient to write custom traceback printers (like web CGI, etc.), and if one is tricky, limit the callers of a function/method to those "allowable". There may be other good reasons, but until you offer a use-case that is compelling for reasons why it should be easier to access and/or modify the contents of stack frames, I'm going to remain at -1000.
I think I was wording this badly. I meant to suggest this as a way to define nested functions (or classes?) and probably access names from various levels of scope. In this way, a nested function would be able to say "bind the name 'a' in the namespace in which I am defined to this object", thus offering more fine grained approached than the current global keyword. I know there has been talk of this issue before, but I don't know if it works with or against anything said for this previously.
And as I have said, if you want people to modify a namespace, you should be creating a namespace and passing it around. If you want people to have access to some embedded definition, then you expose it. If some writer of some module/class/whatever decides that they want to embed some thing that you think should have been exposed to the outside world, then complain the the writer that they have designed it poorly. Take a walk though the standard library. You will likely note the rarity of embedded function/class definitions. In those cases where they are used, it is generally for a good reason. You will also note the general rarity of stack frame access. Prior to the cycle-removing garbage collector, this was because accessing stack frames could result in memory leaks of stack frames. You may also note the rarity of modification of stack frame contents (I'm not sure there are any), which can be quite dangerous. Right now it is difficult to go and access the value of a local 'x' three callers above you in the stack frame. I think this is great, working as intended in fact. Being able to read and/or modify arbitrary stack frame contents, and/or being able to pass those stack frames around: foo(frame[3]), is quite dangerous. I'm still -1000. - Josiah
participants (2)
-
Calvin Spealman -
Josiah Carlson