Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 11 September 2017 at 00:52, Koos Zevenhoven wrote: > On Thu, Sep 7, 2017 at 9:26 PM, Eric Snow > wrote: > [...] > >> >> get_main(): >> >>Return the main interpreter. >> > > I assume the concept of a main interpreter is inherited from the

Re: [Python-ideas] PEP 561: Distributing and Packaging Type Information

On Sun, Sep 10, 2017 at 6:21 PM, Jelle Zijlstra wrote: > > > 2017-09-10 18:10 GMT-07:00 Ethan Smith : > >> >> >> On Sun, Sep 10, 2017 at 5:39 PM, Jelle Zijlstra > > wrote: >> >>> Congratulations on your first PEP! This is

Re: [Python-ideas] PEP 562

Oh, I'm shame myself. Only when `from email import *` is used, __all__ submodules are imported. INADA Naoki On Mon, Sep 11, 2017 at 12:17 PM, Guido van Rossum wrote: > I don't think submodules are automatically imported, unless there are import >

Re: [Python-ideas] PEP 562

I don't think submodules are automatically imported, unless there are import statements in __init__.py. On Sun, Sep 10, 2017 at 8:08 PM, INADA Naoki wrote: > It looks simple and easy to understand. > > To achieve lazy import without breaking backward compatibility, > I

Re: [Python-ideas] PEP 562

It looks simple and easy to understand. To achieve lazy import without breaking backward compatibility, I want to add one more rule: When package defines both of __getattr__ and __all__, automatic import of submodules are disabled (sorry, I don't have pointer to specification about this

Re: [Python-ideas] PEP 561: Distributing and Packaging Type Information

2017-09-10 18:10 GMT-07:00 Ethan Smith : > > > On Sun, Sep 10, 2017 at 5:39 PM, Jelle Zijlstra > wrote: > >> Congratulations on your first PEP! This is solving an important problem >> for typing in Python, so I'm glad we're tackling it. >> > > Thanks!

Re: [Python-ideas] PEP 561: Distributing and Packaging Type Information

On Sun, Sep 10, 2017 at 5:39 PM, Jelle Zijlstra wrote: > Congratulations on your first PEP! This is solving an important problem > for typing in Python, so I'm glad we're tackling it. > Thanks! > > >> >> Furthermore, package authors are wishing to distribute code

Re: [Python-ideas] PEP 561: Distributing and Packaging Type Information

Congratulations on your first PEP! This is solving an important problem for typing in Python, so I'm glad we're tackling it. 2017-09-10 16:05 GMT-07:00 Ethan Smith : > Hello, > > I have just published my first PEP, on packaging type information. I would > appreciate comments

[Python-ideas] PEP 561: Distributing and Packaging Type Information

Hello, I have just published my first PEP, on packaging type information. I would appreciate comments and suggestions. The PEP can be found at https://www.python.org/dev/peps/pep-0561/ I have also duplicated the text below. Thanks! --

Re: [Python-ideas] PEP 562

Sorry for top posting! I'm on a phone. I still think the better way to solve the custom dir() would be to change the module __dir__ method to check if __all__ is defined and use it to generate the result if it exists. This seems like a logical enhancement to me, and I'm planning on writing a

Re: [Python-ideas] PEP 562

The main two use cases I know of for this and PEP 549 are lazy imports of submodules, and deprecating attributes. If we assume that you only want lazy imports to show up in dir() and don't want deprecated attributes to show up in dir() (and I'm not sure this is what you want 100% of the time, but

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,

[Python-ideas] PEP 560

I have written another short PEP that proposes some minor changes to core CPython interpreter for better support of generic types. I will be grateful for comments and suggestions: https://www.python.org/dev/peps/pep-0560/ -- Ivan ___ Python-ideas

Re: [Python-ideas] PEP 562

I'd really love to find a way to enable lazy loading by default, maybe with a way to opt-out old/problem/legacy modules instead of opt-in via __future__ or anything else. IME easily 95%+ of modules in the wild, today, will not even notice (I wrote an application bundler in past that enabled it

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, 7 Sep 2017 21:08:48 -0700 Nathaniel Smith wrote: > > Awesome, thanks for bringing numbers into my wooly-headed theorizing :-). > > On my laptop I actually get a worse result from your benchmark: 531 ms > for 100 MB == ~200 MB/s round-trip, or 400 MB/s one-way. So yeah, >

[Python-ideas] PEP 562

I have written a short PEP as a complement/alternative to PEP 549. I will be grateful for comments and suggestions. The PEP should appear online soon. -- Ivan *** PEP: 562 Title: Module __getattr__ Author: Ivan Levkivskyi

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 9:26 PM, Eric Snow wrote: ​[...]​ > get_main(): > >Return the main interpreter. > > ​I assume the concept of a main interpreter is inherited from the previous levels of support in the C API, but what exactly is the significance of being

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

> On 8 Sep 2017, at 05:11, Eric Snow wrote: > On Thu, Sep 7, 2017 at 3:48 PM, Nathaniel Smith wrote: > >> Numpy is the one I'm >> most familiar with: when we get subinterpreter bugs we close them >> wontfix, because supporting subinterpreters