On 2017-11-15, Koos Zevenhoven wrote:
> Another point, perhaps more difficult to address: Would for instance
> globals() then return a module instead of a dict/mapping?
For compatibility, it would definitely have to return a dict. As a
result, calling globals() would cause the "fast globals" fla
14.11.17 22:34, Neil Schemenauer пише:
This is an idea I have been playing with and seems to hold some
promise. I think we should use a module instance as the standard
global namespace rather than directly using its dict. I have a
prototype version of CPython that does this, not working 100% ye
On Wed, Nov 15, 2017 at 8:44 AM, Nick Coghlan wrote:
>
> I like the idea in principle, but highlighting a particular backwards
> compatibility pain point: one of the complications in importlib is that we
> promise to keep the "sys.modules[__name__] = some_other_object" idiom
> working. That means
On 15 November 2017 at 06:34, Neil Schemenauer wrote:
> So, what is the purpose of all this trouble?
>
> - I believe quite a lot of Python internals can be simpler. For
> example, importlib is complicated by the fact that a dict is
> passed around when most of the logic would prefer to have
This is an idea I have been playing with and seems to hold some
promise. I think we should use a module instance as the standard
global namespace rather than directly using its dict. I have a
prototype version of CPython that does this, not working 100% yet
though.
Major changes:
- In the frame
