Re: [Python-ideas] PEP 562

On Tue, Nov 14, 2017 at 12:24 AM, Serhiy Storchaka wrote: > 10.09.17 21:48, Ivan Levkivskyi пише: > >># lib.py >> >>from warnings import warn >> >>deprecated_names = ["old_function", ...] >> >>def _deprecated_old_function(arg, other): >>... >> >>

Re: [Python-ideas] PEP 562

10.09.17 21:48, Ivan Levkivskyi пише:   # lib.py   from warnings import warn   deprecated_names = ["old_function", ...]   def _deprecated_old_function(arg, other):       ...   def __getattr__(name):       if name in deprecated_names:           warn(f"{name} is deprecated",

Re: [Python-ideas] PEP 562

On 10 November 2017 at 22:27, Guido van Rossum wrote: > Picking up this thread as part of the PEP 562 and PEP 549 review. I like > PEP 562 most, but I propose to add special-casing for `__dir__`. Not quite > as proposed above (making the C level module_dir() look for `__all__`)

Re: [Python-ideas] PEP 562

Picking up this thread as part of the PEP 562 and PEP 549 review. I like PEP 562 most, but I propose to add special-casing for `__dir__`. Not quite as proposed above (making the C level module_dir() look for `__all__`) but a bit more general -- making module_dir() look for `__dir__` and call that

Re: [Python-ideas] PEP 562

On Tue, Sep 12, 2017 at 10:32 PM 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. > I'm down with that. Just make it easier, mucking with sys.modules ain't a

Re: [Python-ideas] PEP 562

On Sep 12, 2017 7:08 AM, "Ionel Cristian Mărieș via Python-ideas" < python-ideas@python.org> wrote: Wouldn't a better approach be a way to customize the type of the module? That would allow people to define behavior for almost anything (__call__, __getattr__, __setattr__, __dir__, various

Re: [Python-ideas] PEP 562

If I recall there was a proposal a few months for a "lazy" keyword that would render anything lazy, including imports. Instead of just adding laziness on generators, the on imports, then who knows where, maybe it's time to consider laziness is a hell of a good general concept and try to

Re: [Python-ideas] PEP 562

Wouldn't a better approach be a way to customize the type of the module? That would allow people to define behavior for almost anything (__call__, __getattr__, __setattr__, __dir__, various operators etc). This question shouldn't exist "why can't I customize behavior X in a module when I can do it

Re: [Python-ideas] PEP 562

@Anthony > module.__getattr__ works pretty well for normal access, after being > imported by another module, but it doesn't properly trigger loading by > functions defined in the module's own namespace. The idea of my PEP is to be very simple (both semantically and in terms of implementation).

Re: [Python-ideas] PEP 562

There's no need for shame! I regularly find out that there are Python features I didn't know about. It's called perpetual learning. :-) On Sun, Sep 10, 2017 at 9:02 PM, INADA Naoki wrote: > Oh, I'm shame myself. > > Only when `from email import *` is used, __all__

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

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

[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