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 mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
