j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
Le 18/09/2017 à 06:40, Cody Piersall a écrit :
On Sun, Sep 17, 2017 at 9:49 PM, Guido van Rossum firstname.lastname@example.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.
In that case, the problem is that jupyter should check up __all__ and act on it. Potentially breaking the language for that seems very overkill.
I'm sure very few code actually depends on the current dir() behavior, but it's more about the social contract of not breaking things unless there is a very good reason.