Re: [Python-ideas] lazy import via __future__ or compiler analysis

On Sep 11, 2017 2:32 PM, "Neil Schemenauer" wrote: On 2017-09-11, Neil Schemenauer wrote: > A module can be a singleton instance of a singleton ModuleType > instance. Maybe more accurate to say each module would have its own unique __class__ associated with it.

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On 2017-09-11, Neil Schemenauer wrote: > A module can be a singleton instance of a singleton ModuleType > instance. Maybe more accurate to say each module would have its own unique __class__ associated with it. So, you can add properties to the class without affecting other modules. For

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On 2017-09-11, C Anthony Risinger wrote: > I'm getting at, is can we find a way to make modules a real type? So dunder > methods are activated? This would make modules phenomenally powerful > instead of just a namespace (or resorting to after the fact __class__ > reassignment hacks). My

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On Mon, Sep 11, 2017 at 1:09 PM, Neil Schemenauer < nas-python-id...@arctrix.com> wrote: > On 2017-09-11, C Anthony Risinger wrote: > > I'm not sure I follow the `exec(code, module)` part from the other > thread. > > `exec` needs a dict to exec code into [..] > [..] > > How do you handle lazy

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On 2017-09-11, C Anthony Risinger wrote: > I'm not sure I follow the `exec(code, module)` part from the other thread. > `exec` needs a dict to exec code into [..] [..] > How do you handle lazy loading when a defined function requests a global > via LOAD_NAME? Are you suggesting to change

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On Fri, Sep 8, 2017 at 11:36 AM, Neil Schemenauer < nas-python-id...@arctrix.com> wrote: > On 2017-09-09, Chris Angelico wrote: > > Laziness has to be complete - or, looking the other way, eager > > importing is infectious. For foo to be lazy, bar also has to be lazy; > > Not with the approach

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On Sat, Sep 9, 2017 at 2:36 AM, Neil Schemenauer wrote: > On 2017-09-09, Chris Angelico wrote: >> Laziness has to be complete - or, looking the other way, eager >> importing is infectious. For foo to be lazy, bar also has to be lazy; > > Not with the approach I'm

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On 2017-09-08, Joshua Morton wrote: > In general this won't work. It's not generally possible to know if a given > statement has side effects or not. That's true but with the AST static analysis, we find anything that has potential side effects. The question if any useful subset of real modules

Re: [Python-ideas] lazy import via __future__ or compiler analysis

Replying here, although this was written in response to the other thread: Hey Neil, In general this won't work. It's not generally possible to know if a given statement has side effects or not. As an example, one normally wouldn't expect function or class definition to have side effects, but if

Re: [Python-ideas] lazy import via __future__ or compiler analysis

Barry Warsaw wrote: > There are a few other things that might end up marking a module as > "industrious" (my thesaurus's antonym for "lazy"). Good points. The analysis can be simple at first and then we can enhance it to be smarter about what is okay and still lazy load. We

Re: [Python-ideas] lazy import via __future__ or compiler analysis

Neil Schemenauer wrote: > Introduce a lazy module import process that modules can opt-in to. > The opt-in would either be with a __future__ statement or the > compiler would statically analyze the module and determine if it is > safe. E.g. if the module has no module level statements besides >

[Python-ideas] lazy import via __future__ or compiler analysis

This is a half baked idea that perhaps could work. Maybe call it 2-stage module load instead of lazy. Introduce a lazy module import process that modules can opt-in to. The opt-in would either be with a __future__ statement or the compiler would statically analyze the module and determine if it