On Fri, Dec 08, 2017 at 09:51:00PM +0100, Xen wrote:
> It was pushed upon an unwilling community
Oh, please. I don't think anyone's going to argue that it's been the
best-managed transition in the history of ever: it's true that it
effectively split the community for a while, a lot of work has had to be
put into porting work that might otherwise have been spent on other
things, and we're still in a situation where many newer facilities have
remained inaccessible to developers of older projects for longer than
they ordinarily would have done. None of these things is anything like
ideal. But framing it as a dichotomy between those nasty developers and
an unwilling community of consumers is facile; it is by no means that
simple. Plenty of folks in the Python community have recognised that,
even if it isn't an ideal situation, there are good reasons behind many
of the changes in Python 3 and they've put lots of energy into helping
out.
In any case, there is really very little point in tilting at this
windmill now, unless your goal is to expend further energy.
> But I was going to say 2 years might seem like a lot, or 3 years, but it is
> nothing.
It's been obvious for nearly ten years now that Python 2 was going to
reach the end of the road eventually; once the incompatible changes to
the language landed, it was naïve to expect that Python 2 would continue
to be maintained indefinitely. Anybody who's only suddenly noticing it
really hasn't been paying attention at all.
> Meanwhile we can still run C programs from 1980, basically.
>
> Or whereabouts, at least.
Interesting you should say that, because (just to take one example) the
attitude to undefined behaviour in compilers has changed a great deal
since 1980. Your C program written back then may still manage to
compile with sufficient "please run in ancient mode" compiler options,
but will it behave as expected if nobody has maintained it in nearly 40
years? Who can say, but probably only if it's very simple and you're
quite lucky. And in fact unless it's the simplest possible kind of
program with almost no system dependencies, you'll probably have to
spend at least some effort bringing it up to date with post-Neolithic
header names and function signatures.
Admittedly I only have experience of maintaining moderate-sized C
programs that hailed from the 1990s rather than the 1980s, but in my
experience the work involved in keeping that sort of thing up to date
isn't significantly different from the work involved in doing the same
for similarly-sized Python projects. (That is, if it's more than a
couple of thousand lines or so then somebody probably needs to be
actively maintaining the thing even if its basic functionality is
static, and you're going to have to occasionally deal with changes in
the language or its runtime facilities, changes in your dependencies,
and stuff you just missed.)
> I think you can definitely find a way to compile most programs from 1990...
Similarly, I'm sure it will remain possible to dig up Python 2 and
continue to use it for many years to come, even after it's no longer
supported upstream and no longer in Ubuntu.
Whether that's a good idea after nobody is taking responsibility for
security updates to the core language or the standard library, and after
the libraries you depend on have dropped Python 2 support so you're
stuck on older versions, is up to you to decide. If it's at all
network-facing, then anyone with a reasonable sense of responsibility
realised some time ago that they need to keep their dependencies up to
date. If it's entirely self-contained, then maybe it's fine; to save on
maintaining your own Python build, you could perhaps run it in a
container running an older version of the OS. Or if the program is
simple you may well just be able to run 2to3 over it and at least get
most of the way there.
But unless it's really enormous, it's probably not all that hard to port
anyway. Putting a clear bytes/text distinction in place if you didn't
have one already can be tedious, sure, but it generally makes things
better; most of the rest is easy by comparison; and nowadays there are
several good libraries and strategies to help.
Lest anyone think I'm casually underestimating the work involved, I'm
speaking here as a Launchpad developer: three-quarters of a million
lines of Python code, and a couple of hundred dependencies. Sure, we're
still on Python 2, which is a problem: other projects have generally
taken precedence and porting has been a back-burner task. But a large
part of the work we need to do is work we'd have needed to do anyway,
such as bringing many of those dependencies up to date or finding
better-maintained versions of some of them, and we have at least the
skeleton of a plan. I feel quite safe in saying that for most Python
programs it would be a great deal easier than this.
--
Colin Watson [cjwat...@ubuntu.com]
--
Ubuntu-devel-discuss mail
