[Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?

[Nick Coghlan]

On 17 August 2014 12:43, Guido van Rossum <guido at python.org> wrote:
> On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> I've also had people express the concern that "you broke compatibility
>> in a major way once, how do we know you won't do it again?".
>
>
> Well, they won't, really. You can't predict the future. But really, that's a
> pretty poor way to say "please don't do it again."
>
> I'm not sure why, but I hate when someone starts a suggestion or a question
> with "why doesn't Python ..." and I have to fight the urge to reply in a
> flippant way without answering the real question. (And just now I did it
> again.)
>
> I suppose this phrasing may actually be meant as a form of politeness, but
> to me it often sounds passive-aggressive, pretend-polite. (Could it be a
> matter of cultural difference? The internet is full of broken English, my
> own often included.)

I don't mind it if the typical answers are accepted as valid:

*  "because it has these downsides, and those are considered to
outweigh the benefits"
*  "because it's difficult, and it never bothered anyone enough for
them to put in the work to do something about it"

Those aren't always obvious, especially to folks that don't have a lot
of experience with long lived software projects (I had only just
started high school when Python was first released!), so I don't mind
explaining them when I have time.

>> Both of those contrast strongly with Guido's stated position that he
>> never wants to go through a transition like the 2->3 one again.
>
> Right. What's more, when I say that, I don't mean that you should wait until
> I retire -- I think it's genuinely a bad idea.

Absolutely agreed - I think the Unicode change was worthwhile (even
with the impact proving to be higher than expected), but there isn't
any such fundamental change to the data model lurking for Python 3.

> I also don't expect that it'll be necessary -- in fact, I am counting on
> tools (e.g. static analysis!) to improve to the point where there won't be a
> reason for such a transition.

The fact that things like Hylang and MacroPy can already run on the
CPython VM also shows that other features (like import hooks and the
AST compiler) have evolved to the point where the Python data model
and runtime semantics can be more effectively decoupled from syntactic
details.

> (Don't understand this to mean that we should never deprecate things.
> Deprecations will happen, they are necessary for the evolution of any
> programming language. But they won't ever hurt in the way that Python 3
> hurt.)

Right. I think Python 2 has been stable for so long that I sometimes
wonder if folks forget (or never knew?) we used to deprecate things
within the Python 2 series as well, such that code that ran on Python
2.x wasn't necessarily guaranteed to run on Python 2.(x+2). "Never
deprecate anything" is a recipe for unbounded growth in complexity.

Benjamin has made a decent start on documenting that normal
deprecation process in PEP 387, so I'd also suggest refining that a
bit and getting it to "Accepted" as part of any explicit "Python 4.x
won't be as disruptive as 3.x" clarification.

>> no plans to create a Python 2.8 release. Would it be worth writing a
>> similarly explicit "not an option" PEP explaining that the regular
>> deprecation and removal process (roughly documented in PEP 387) is the
>> *only* deprecation and removal process? It could also point to the
>> fact that we now have PEP 411 (provisional APIs) to help reduce our
>> chances of being locked indefinitely into design decisions we aren't
>> happy with.
>>
>> If folks (most significantly, Guido) are amenable to the idea, it
>>
>> shouldn't take long to put such a PEP together, and I think it could
>> help reduce some of the confusions around the expectations for Python
>> 4.0 and the evolution of 3.x in general.
>
> But what should it say?

The specific things I was thinking we could point out were:

- PEP 387, documenting the normal deprecation process that existed
even in Python 2
- highlighting the increased preference for "documented deprecation
only" in cases where maintaining something isn't actively causing
problems, there are just better alternatives now available
- PEP 411, the (still relatively new) provisional API concept
- PEP 405, adding pyvenv as a standard part of Python
- PEP 453, better integrating PyPI into the recommended way of working
with the language

Those all help change the way the language evolves, as they reduce the
pressure to rush things into the standard library before they're
ready, while at the same time giving us a chance to publish "not quite
ready to be locked down" features for very broad feedback.

I'd also point out that the "variable encodings" to "Unicode"
transition for text handling is an industry wide issue, one which even
operating systems are still struggling with in some cases. POSIX-only
software that only needs to run on modern platforms can assume UTF-8,
while modern Windows and Java only software can largely assume
UTF-16-LE, but anyone trying to integrate with both is going to have a
far more interesting time of things (as we've discovered the hard
way). That transition is the core thing that sometimes makes migrating
from Python 2 to Python 3 non-trivial - even the changes to dict are
relatively simple to address by comparison.

> It's easy to say there won't be a 2.8 because we
> already have 3.0 (and 3.1, and 3.2, and ...). But can we really say there
> won't be a 4.0? Never? Why not?

I'm assuming there *will* be a 4.0 - I'd just like to see it be "the
release after Python 3.9", rather than being spectacularly different
from the preceding 3.x releases. That's similar to the way that the
Linux kernel shifted to the 3.x series not because of any particular
milestone, but just due to the sheer weight of accumulated changes
relative to the early 2.x releases.

> Who is to say that at some point some folks
> won't be going off on their own to design a whole new language and name it
> Python 4, following Larry Wall's Perl 6 example?

Based on the examples of both Python 3 and Perl 6, I'd personally
strongly advocate for such a project to be a new language with a
different name, even if it was created and maintained by python-dev :)

> I think it makes sense to occasionally remind the more eager contributors
> that we want the future to come gently (that's not to say in our sleep :-).
> But I'm not sure a PEP is the best form for such a reminder. Even the Pope
> has a Twitter account. :-)

Yeah, I'm not sure a PEP is the right way either. However, it seemed
to get the point across for both PEP 404 ("no Python 2.8") and PEP 394
("POSIX platforms: don't make /usr/bin/python refer to Python 3, you
break things when you do that"), so I figured I'd at least raise the
suggestion on this topic as well.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia