On Sun, Sep 17, 2017 at 9:49 PM, Guido van Rossum <gu...@python.org> 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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
