Gregory Ewing greg.ew...@canterbury.ac.nz:
I didn't think that using a custom mapping object for globals was
officially supported. Has that changed?
The documentation is a bit vague about it:
If only globals is provided, it must be a dictionary, which will be
used for both the global
On Friday, June 13, 2014 8:07:45 AM UTC+2, Marko Rauhamaa wrote:
The documentation is a bit vague about it:
If only globals is provided, it must be a dictionary, which will be
used for both the global and the local variables. If globals and
locals are given, they are used for the
rob...@robertlehmann.de wrote:
On Friday, June 13, 2014 8:07:45 AM UTC+2, Marko Rauhamaa wrote:
The documentation is a bit vague about it:
If only globals is provided, it must be a dictionary, which will be
used for both the global and the local variables. If globals and
locals
Hello,
On Fri, 13 Jun 2014 12:53:54 +0200
Peter Otten __pete...@web.de wrote:
[]
exec(fun.__code__, {}, Namespace())
Neither __getitem__ nor __setitem__ seem to be called on the local
variables.
Accessing fun.__code__ is clever, but unfortunately the compiler
produces different
Paul Sokolovsky pmis...@gmail.com:
And people should decide what they really want - fast language which
can stand against the competition, or language with dynamicity and
reflection capabilities beyond any practical need. I make first choice
any time.
I'm in the latter camp, absolutely,
Hi all,
I have noticed there is a slight asymmetry in the way the interpreter
(v3.3.5, reproduced also in v3.5.x) loads and stores globals. While
loading globals from a custom mapping triggers __getitem__ just fine,
writing seems to silently ignore __setitem__.
class Namespace(dict):
def
On Thu, Jun 12, 2014 at 12:18 PM, Robert Lehmann m...@robertlehmann.de wrote:
Hi all,
I have noticed there is a slight asymmetry in the way the interpreter
(v3.3.5, reproduced also in v3.5.x) loads and stores globals. While loading
globals from a custom mapping triggers __getitem__ just
On Fri, Jun 13, 2014 at 4:18 AM, Robert Lehmann m...@robertlehmann.de wrote:
PS. I found a 3.3.x commit (e3ab8aa) which fixed the LOAD_GLOBAL opcode to
support other types than dict, but STORE_GLOBAL seems to use bare
PyDict_SetItem instead of dispatching to PyObject_SetItem.
This looks like
Robert Lehmann wrote:
I have noticed there is a slight asymmetry in the way the interpreter
(v3.3.5, reproduced also in v3.5.x) loads and stores globals. While
loading globals from a custom mapping triggers __getitem__ just fine,
writing seems to silently ignore __setitem__.
I didn't think
