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 <cody.piersall@gmail.com> wrote:
On Tue, Sep 12, 2017 at 3:26 AM, Ivan Levkivskyi <levkivskyi@gmail.com> 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)