Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)
Le 18/09/2017 à 06:40, Cody Piersall a écrit : > 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. 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/
Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)
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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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) ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Use __all__ for dir(module) (Was: PEP 562)
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/
