[Python-ideas] Use __all__ for dir(module) (Was: PEP 562)
Cody Piersall
cody.piersall at gmail.com
Sun Sep 17 22:34:59 EDT 2017
More information about the Python-ideas mailing list
Sun Sep 17 22:34:59 EDT 2017
- Previous message (by thread): [Python-ideas] Fwd: Fwd: A PEP to define basical metric which allows to guarantee minimal code quality
- Next message (by thread): [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Sep 12, 2017 at 3:26 AM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote: > @Cody >> 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 patch to implement this. Whether it >> would be accepted is still an open issue though. > > This seems a reasonable rule to me, I can also make this patch if > you will not have time. I submitted a PR:https://github.com/python/cpython/pull/3610 and a BPO issue: https://bugs.python.org/issue31503 R. David Murray pointed out that this is a backwards-incompatible change. This is technically true, but I don't know of any code that depends on this behavior. (Of course, that does not mean it does not exist!) >From my perspective, the big benefit of this change is that tab-completion will get better for libraries which are already defining __all__. This will make for a better REPL experience. The only code in the stdlib that broke were tests in test_pkg which were explicitly checking the return value of dir(). Apart from that, nothing broke. If a module does not have __all__ defined, then nothing changes for that module. Cody
- Previous message (by thread): [Python-ideas] Fwd: Fwd: A PEP to define basical metric which allows to guarantee minimal code quality
- Next message (by thread): [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list