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 docum
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 but
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
Python-ideas@python.
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 over
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 (ha
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 already.
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. __load_
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
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
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 wo
On 2017-09-12, Nathaniel Smith wrote:
> If you're ok with replacing the object in sys.modules then the ability to
> totally customize your module's type has existed since the dawn era. And if
> you're not ok with that, then it's still existed since 3.5 via the
> mechanism of assigning to __class__
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 (
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 retu
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
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 __namespac
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 function._
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
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 proposing. bar will be loaded in non-lazy
fashion at the right time, foo can still be lazy.
_
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 p
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 transf
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
may evolve it over t
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 i
22 matches
Mail list logo
