[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)
From:       Michel Desmoulin <desmoulinmichel () gmail ! com>
Date:       2017-09-18 6:35:40
Message-ID: 72d6cd37-187d-317b-7f51-1909bad66faa () gmail ! com
[Download RAW message or body]


Le 18/09/2017 à 06:40, Cody Piersall a écrit  :
> On Sun, Sep 17, 2017 at 9:49 PM, Guido van Rossum <guido@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.

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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[prev in list] [next in list] [prev in thread] [next in thread]