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

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

[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

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

[Python-ideas] Lazy creation of module level functions and classes

This is an idea that come out of the lazy loading modules idea. Larry Hastings mentioned what a good improvement this was for PHP. I think it would help a lot of Python too. Very many functions and classes are not actually needed but are instantiated anyhow. Back of napkin idea: Write AST

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

On 2017-09-12, Eric Snow wrote: > Yeah, good luck! :). If I weren't otherwise occupied with my own crazy > endeavor I'd lend a hand. No problem. It makes sense to have a proof of concept before spending time on a PEP. If the idea breaks too much old code it is not going to happen. So, I will

Re: [Python-ideas] PEP 562

On 2017-09-10, Neil Schemenauer wrote: > I have something 90% working, only 90% left to go. ;-) Prototype: https://github.com/warsaw/lazyimport/blob/master/lazy_demo.py https://github.com/nascheme/cpython/tree/exec_mod Next step is to do the compiler and change importlib to do exec(code, mod

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 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 m

[Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

This is my idea of making module properties work. It is necessary for various lazy-loading module ideas and it cleans up the language IMHO. I think it may be possible to do it with minimal backwards compatibility problems and performance regression. To me, the main issue with module properties

Re: [Python-ideas] Hexadecimal floating literals

On 2017-09-12, Victor Stinner wrote: > Instead of modifying the Python grammar, the alternative is to enhance > float(str) to support it: > > k = float("0x1.2492492492492p-3") # 1/7 Making it a different function from float() would avoid backwards compatibility issues. I.e. float() no longer

[Python-ideas] Modules as global namespaces rather than dicts

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

[Python-ideas] Provide a way to import module without exec body

I have been working on reducing Python statup time. It would be nice if there was some way to load a module into memory without exec of its body code. I'm sure other people have wished for this. Perhaps there could be a new special function, similar to __import__ for this purpose. E.g.

Re: [Python-ideas] Modules as global namespaces rather than dicts

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"

[Python-ideas] f-string literals by default?

I think most people who have tried f-strings have found them handy. Could we transition to making default string literal into an f-string? I think there is a smooth migration path. f-strings without embedded expressions already compile to the same bytecode as normal string literals. I.e. no

Re: [Python-ideas] f-string literals by default?

On 2017-12-05, Joseph Jevnik wrote: > This would break code that uses str.format everywhere for very > little benefit. That is a very strong reason not to do it. I think we can end this thread. Thanks. ___ Python-ideas mailing list

Re: [Python-ideas] Provide a way to import module without exec body

On 2017-12-03, Nick Coghlan wrote: > There'd be some subtleties around handling backwards compatibility > with __import__ overrides (essentially, CREATE_MODULE would have to > revert to doing all the work, while EXEC_MODULE would become a no-op), > but the basic idea seems plausible. Right now

Re: [Python-ideas] Provide a way to import module without exec body

On 2017-12-01, Chris Angelico wrote: > Can you elaborate on where this is useful, please? Introspection tools, for example, might want to look at the module without executing it. Also, it is a building block to make lazy loading of modules work. As Nick points out, importlib can do this

[Python-ideas] Link accepted PEPs to their whatsnew section?

I'm testing "Data Classes" for Python 3.7. Awesome new feature, BTW. The PEP is the first search result when I lookup "dataclass python". Given that the PEP is not the best documentation for an end user, I wonder if we should have a link in the header section of the PEP that goes to better

Re: [Python-ideas] Move optional data out of pyc files

On 2018-04-12, M.-A. Lemburg wrote: > This leaves the proposal to restructure pyc files into a sectioned > file and possibly indexed file to make access to (lazily) loaded > parts faster. I would like to see a format can hold one or more modules in a single file. Something like the zip format