FWIW, I actually like the idea - though not strongly enough to really campaign for it. My reasoning is that I think that both the current "consenting adults" policy and possibly more importantly the fact that we are implicitly supporting private interfaces by our reluctance to changing them has harmed the ecosystem of Python interpreters. Because the lines between implementation details and deliberate functionality are very fuzzy, alternate implementations need to go out of their way to be something like "bug compatible" with CPython. Of course, there are all kinds of other psychological and practical reasons that are preventing a flourishing ecosystem of alternative Python implementations, but I do think that we could stand to be more strict about reliance on implementation details as a way of standing up for people who don't have the resources or market position to push people to write their code in a way that's compatible with multiple implementations. I'll note that I am basically neutral on the idea of consistency across the codebase as a goal - it would be nice but there are too many inconsistencies even in the public portion of the API for us to ever actually achieve it, so I don't think it's critical. The main reason I like the idea is that I /do/ think that there are a lot of people who use "does it start with an underscore" as their only heuristic for whether or not something is private (particularly since that is obvious to assess no matter how you access the function/method/attribute/class, whereas `__all__` is extra work and many people don't know its significance). Yes, they are just as wrong as people who we would be breaking by sweeping changes to the private interface, but the rename would prevent more /accidental/ reliance on implementation details. On 7/23/19 3:27 AM, Paul Moore wrote:
On Tue, 23 Jul 2019 at 04:58, Kyle Stanley <aeros167@gmail.com> wrote:
My primary motivation was to provide more explicit declaration of public vs private, not only for the purpose of shifting the responsibility to the authors, but also to shift the liability of using private members to the user. My view is that the current somewhat adhoc, "consenting adults" approach has served us well for many years now. There have been a few cases where we've needed to address specific points of confusion, but mostly things have worked fine.
With Python's increased popularity, there has been an influx of new users with less familiarity with Python's easy-going attitude, and consequently an increase in pressure for more "definite", or "explicit" rules. While it's great to see newcomers arrive with new ideas, and it's important to make their learning experience as pleasant as possible, we should also make sure that we don't lose the aspects of Python that *made* it popular in the process. And to my mind, that easy-going, "assume the users know what they are doing" attitude is a key part of Python's appeal.
So I'm -1 on any global change of this nature, particularly if it is motivated by broad, general ideas of tightening up rules or making contracts more explicit rather than a specific issue.
The key point about making changes on a "case by case" basis is *not* about doing bits of the fix when needed, but about having clear, practical issues that need addressing, to guide the decision on what particular fix is appropriate in any given situation.
Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QB436KAE...