Paul Sokolovsky :
> 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, except that I have
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
> produ
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
>
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
Gregory Ewing :
> 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 and the local variables. If
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 t
On Fri, Jun 13, 2014 at 4:18 AM, Robert Lehmann 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 something for a t
On Thu, Jun 12, 2014 at 12:18 PM, Robert Lehmann 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 fine, writing seems
>
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 __g
