On Sun, Sep 17, 2017 at 9:49 PM, Guido van Rossum wrote:

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?

...

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.

I'm sorry, I should have been more specific here. The tab completion provided by Jupyter uses dir() to provide the relevant tab-completion options. I was motivated to put this PR together whenever someone (I think Nathaniel Smith) was talking about setting a custom __dir__ on a module by overriding class, and IIRC his motivation was so that no one tab-completes to use a deprecated attribute. I spend a _lot_ of time in a Jupyter environment, so most of my tab completion is provided by whatever dir() returns. I think this is a pretty common setup. The default REPL also uses dir() for populating the completion list. Since my only interaction with dir() has to do with tab completion, I may be unaware of use cases where this PR would actually break working code. I understand (and agree with!) the emphasis the Python developers place on backwards compatibility, but I just can't think of code that would be broken by this change. Of course, that doesn't mean it doesn't exist! Cody