Both Peters :) Sure, I must concede that the problem here was my expectation of how things should work.
Thanks for the explanations. I still don't really know whether this behaviour of locals() is the result of a design decision, or an implementation artifact of CPython, but at least I have a clear idea of how to play nice with locals(). thx Caleb Peter Otten wrote: > Caleb Hattingh wrote: > > > I am convinced now that locals() doesn't work as (I) expected. Steven > > says there was some or other reason why locals() as used in this context > > is not writable - Do you know why this is? I really do not like > > guidelines like "may not work", "is unreliable" and so on. Perhaps this > > is a character flaw, but I really do like to know what works, when it > > works, and when it doesn't work. > > I think Peter Hansen has answered that. Your expectations were just wrong. > > > In this scenario, we can see it doesn't work. To my eyes, it doesn't work > > *in the way I expect* (which is highly subjective, no argument there). > > Would this be a situation where it would be nice to have an exception > > thrown if locals() is assigned to in a scope where it is not writable? > > If python were to throw an exception, it should always be thrown. But I'm > the wrong one to worry about that as I didn't even find a single > > globals()[name] = value > > assignment in my scripts. I want to know a variable's name, or I put it in a > dictionary. > > > It would also be nice if globals and locals behaved the same, differing > > only in scope (which is what I expected originally anyway). But we can't > > have everything, I guess :) > > That would mean that both would become read-only, I guess, but I don't see > that happen. > > Peter -- http://mail.python.org/mailman/listinfo/python-list
