Python2 demotion (moving from main to universe) in progress

[Colin Watson]

On Sat, Dec 09, 2017 at 12:47:28PM +0100, Xen wrote:
> Colin Watson schreef op 09-12-2017 0:24:
> > there are good reasons behind many of the changes in Python 3
> 
> You know, an appeal to "good reasons" is really a blanket statement that
> betrays the absence of any good reasons.

No, it betrays limited time to write.  To take just one example, Python
2's willingness to mix Unicode and binary types provided that the binary
strings were limited to 7-bit ASCII was the cause of a large number of
bugs over the years, which Anglophones tended to overlook and allow to
reach production code because they rarely use characters outside ASCII.
Even as somebody generally very sympathetic to the needs of
localisation, I've got this wrong because Python 2 had just too many
ways to make mistakes in this area.  In Python 3 you have to confront
the distinction earlier and have a much better chance of getting it
right.  You can certainly begin to make the distinction in Python 2
code, but adding the extra type-safety required a breaking change.

I'm not going to continue to spend time explaining the underlying
reasons in response to vague insinuations, though.  If there are some
particular changes in Python 3 that you think weren't well-founded, name
them.  This is a list for developers; we can be specific.

> So you go on to detail the similarities with C but with C there never was
> one breaking point, just incremental changes.

There have been many breaking changes in C over the years, though since
it's an essentially smaller language most of those changes (not all!)
have been at the runtime or library levels.  Small consolation if that's
what breaks your code, of course.

But you seem to be under the impression that moving from Python 2 to
Python 3 requires non-incremental changes: i.e. a flag day where your
code stops working on Python 2 and starts working on Python 3.  This
isn't so.  There's a large subset that works fine in both: nearly all
the code I write these days is "bilingual" in this way, and the obvious
porting strategy for most code involves making it be this way, so at the
end all you have to do is flip to the newer interpreter after your tests
pass.

I would rather that Python 3 had taken the Perl 6 approach of having the
newer interpreter be able to execute older code in a special
compatibility mode, so that we could mix-and-match more freely and the
transition would have been easier.  On the other hand, it's not at all
obvious how text/bytes types would have worked across the boundary.
(And, much though I like Perl, Perl 6 has taken even longer to get into
typical developers' hands than Python 3 has, so ...)

> The work of "God" (unfortunate events) should not be willfully perpetrated
> by humans on one another on purpose.

What is your *concrete* proposal here?  Bear in mind that we don't have
the resources to maintain Python 2 indefinitely; if that's your
proposal, it's going to run up against real-world constraints.  But
there may be other things we can do to make it easier for people.  Do
you have some specific projects that are troublesome?

-- 
Colin Watson                                       [cjwatson at ubuntu.com]