Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)

I ave to agree with the other committers who already spoke up. I'm not using tab completion much (I have a cranky old Emacs setup), but isn't making tab completion better a job for editor authors (or language-support-for-editor authors) rather than for the core language? What editor are you using that calls dir() for tab completion? On Sun, Sep 17, 2017 at 7:34 PM, Cody Piersall wrote:

On Tue, Sep 12, 2017 at 3:26 AM, Ivan Levkivskyi 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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)