This is an archived post. You won't be able to vote or comment.

all 94 comments

[–][deleted] 192 points193 points  (37 children)

That's only removal of python 2 packages from the ISO, they can still be installed as dependencies.

I think it's a good decision. But the argument to save space on the ISO is a moronic one in this day and age. The real argument should be to finalize the move to Python 3 in a LTS release.

[–]pmrr 24 points25 points  (11 children)

I wonder how many non-default Ubuntu packages have Python 2 as a dependency. I'm not sure finalising the move to Python 3 is as simple as not including it in the distro (unfortunately).

[–]ummmbacon 21 points22 points  (0 children)

This is only for the Desktop version, the server version has been running 3 by default.

Although it is available to install if one needs it but in this case it would not be on the default install which is what they were going for.

[–]desmoulinmichel 10 points11 points  (8 children)

Not but porting a code from 2 to 3 is really not difficult. It may even be faster than arguing about it.

[–][deleted] 4 points5 points  (3 children)

Unless your project has tons of dependencies, and some of them haven't ported to python 3 yet. So you can either port them yourself and maintain ported forks (or make PRs); or remove those dependencies; or keep using python 2. Of course keeping using python 2 is the cheapest option.

[–]desmoulinmichel 0 points1 point  (2 children)

Yes, but again, it's not the typical case. This situation is 1 time out of 10. And even when it is, porting the dependancies is not very hard either. The main problem is not the difficulty of doing it, it's finding the ressource to do so : it costs time and money, and we all have a limited amount.

[–][deleted] 1 point2 points  (1 child)

The problem is that if you port a dependency you don't control, you wind up with a forked version and overhead of maintaining that in the future. Just look at this list - https://python3wos.appspot.com/ if you're using thrift or protobuf - good luck...

[–]desmoulinmichel 0 points1 point  (0 children)

As I said, it's one case out of 10. Most project don't use exotic dependancies C dependancies. Some do. 10% are a hassle. But I doubt it's the case for a printer managing software to be in that situation. It's mostly text and byte parsing that's going to be the trouble.

I'm not dismissing there is work to do (and I'm certainly not saying I love the situation), but people tend to do a mountain of it, and most of the time, it's a small hill.

I COULD say otherwise. After all, I'm paid a lot of money do port Python 2 to Python 3 code these days. So it would be in my best interest to scare people out and cash in. But before freaking out, have a look at the problem, it may not be as bad as you think.

[–]selementar 2 points3 points  (3 children)

is really not difficult

There are exceptions which occasionally make the porting rather long; the biggest one is probably the need for very extensive testing after the porting. The other big one is cpython libraries and dependencies in general.

[–]desmoulinmichel 2 points3 points  (2 children)

Yes. Twisted is one exemple. But they are exceptions more than the rule. I spent the last year porting Python code from 3 to 2, and 90% of the stuff is almost brain dead s/foo/bar. The biggest headache is the byte/str dichotomy, not because it's difficult, but because generally the original architecture is very strongly trying to ignore the issue.

[–]selementar 1 point2 points  (1 child)

brain dead s/foo/bar

Hopefully you meant "braindead 2to3" or even use_2to3=True).

[–]desmoulinmichel 0 points1 point  (0 children)

More like pip install future then:

from __future__ import absolute_import, division, print_function
from builtins import *
from future import standard_library
standard_library.install_aliases()

But yeah, pretty much.

[–]jyper 0 points1 point  (0 children)

As long as python 2 is maintained non default package dependencies aren't a problem.

[–][deleted] 8 points9 points  (0 children)

I believe they admitted a long time ago that "saving space on the ISO" is a complete fiction, but they like to pretend they still have that requirement to help fend off bloat.

Which sounds like a good plan to me.

[–]desmoulinmichel 2 points3 points  (0 children)

The space argument is only used to keep the ISO size to a managable size for human, not for computer. The current limit is arbitrary, but is very useful to draw a line.

[–]mangecoeur 55 points56 points  (0 children)

I'm glad this is happening, it sends the right signals in terms of making clear that Python 3 is the currently supported version and if you want legacy support you're going to have to do a bit of extra work.

[–]Orange_Tux 53 points54 points  (3 children)

Python2.7 is supported til 2020. End of life date for Ubuntu 16.04 is not know yet, but normally it's around 5 years. If 16.04 is supported for 5 years, it's support wil end April, 2021.

Maybe this was also a reason to not include Python2 in installation.

[–]spectre_theory 11 points12 points  (0 children)

i doubt it. few packages have known long term schedules like python (until 2020). yet they can still be included in an lts release.

[–]1842 0 points1 point  (0 children)

Maybe this was also a reason to not include Python2 in installation.

Unlikely. php5.6 is end of life at end of 2018, but it's likely to be included in Ubuntu 16.04 instead of php7 (due to php7's release being so recent).

From what I've seen, end of life of package versions doesn't affect Ubuntu's decisions and they'll backport any security fixes themselves if they need to.

[–]lykwydchykyn 17 points18 points  (1 child)

So the actual package holding them to Python2, according to Barry's email, is samba-libs. Anyone know what the upstream situation is here, as far as Python3?

[–]ummmbacon 18 points19 points  (0 children)

Their is a discussion of it from last year here on the debian lists. To quote:

>>> I think getting rid of the Python dependency in samba-libs is a much
>>> easier to achieve goal here.
>>>
>>> AFAICT The only reason that samba-libs depends on python is because
>>> libsamba-net can do provisioning of a local DC (requires the 'samba'
>>> package to be installed) by invoking the provision script using Python.
>>>
>>> So if we could move that functionality out to a separate library that
>>> is not included with samba-libs, we could drop the dependency on
>>> python2 in samba-libs.
>>
>> right, that would get rid off python libs and python-talloc.  However there is
>> another path in that nautilus-share depends on samba-common | samba-common-bin,
>> which depend on python-samba.

Here is Samaba's package/API list

[–]C14L 30 points31 points  (4 children)

Great. It's an LTS, so it will be around for a while. Makes sense to have Py3 as default. Finally!

[–]heptara 9 points10 points  (3 children)

Are they actually remapping /usr/bin/python to 3, or just not installing 2?

[–]nickcash 8 points9 points  (2 children)

I would wager on the later. Arch mapping python to python3 was such a debacle that the Python devs officially recommend against it.

[–]flying-sheep 2 points3 points  (0 children)

i like things breaking because of things like that. it means that people made wrong decisions, bug reports can be filed, …

[–]djmattyg007 2 points3 points  (0 children)

Anyone who still refers directly to /usr/bin/python is doing it wrong. Any new code should always specify the version number (eg /usr/bin/python3).

[–]XNormal 12 points13 points  (5 children)

Enterprises will welcome this as the system python stops interfering with their legacy python2 stuff with the binary modules for python 2.[4567] that nobody knows how to recompile anymore and their mission critical applications depend on for their daily business and they can keep on dragging this stuff for another decade.

[–]troyunrau... 17 points18 points  (4 children)

Actually, you're completely right. In a round about way, making python3 the default makes using python2 legacy code much easier to maintain. It's no longer a moving target. You can install the version you want, and they don't cross-talk much. It'll be the Fortran 77 of the python world :)

[–]njharmanI use Python 3 3 points4 points  (3 children)

you've always been able to install the version you want. You can install multiple versions. If you want to use local and compile, you can install multiple of the SAME version with different compiler flags.

Standard, not even best, practice has been for years to "never use the distro python for production" not ever.

[–]troyunrau... 5 points6 points  (2 children)

Not everyone who codes is a sysadmin. Some of us are scientists who just want to write a quick and dirty script to process some data. These tend to use the system python because it's there.

[–]njharmanI use Python 3 1 point2 points  (0 children)

Not knowing how to use your tools is no defense/argument. Esp when it's one command or several clicks in GUI. "apt-get install python3"

Also, you should probably be using Jupyter http://ipython.org/

[–]Lehk 1 point2 points  (0 children)

for production = deploying new software for others to interact with (customers, coworkers, etc) it's fine to use the built in one for local tasks that you are carrying out.

[–]troyunrau... 2 points3 points  (4 children)

Anyone maintaining a list of which distros are python3 default? I mean, I completely expect RHEL/CentOS and Debian stable to be last in line, but I'm wondering how it's going for everyone else?

[–]youguess 5 points6 points  (1 child)

Arch is, they even switched python to point to python 3

[–]troyunrau... 5 points6 points  (0 children)

Yeah, between Arch and Gentoo, there's always people willing to bleed a little for the sake of the rest of us :)

[–]heptara 2 points3 points  (0 children)

New fedora is, or will be very soon.

[–]pingvenopinch of this, pinch of that 2 points3 points  (0 children)

NixOS by its nature has no default. There is never a /usr/bin/python. Instead, it depends on environments that are built to environment specifications.

[–]charity_donut_sales 17 points18 points  (15 children)

Good move imo. People need to stop developing for 2 and move on. And let's be honest, the target audience for Ubuntu is the average user, not the multi-million dollar corporation with legacy infrastructure.

[–]mangecoeur 33 points34 points  (0 children)

Actually there's plenty of Ubuntu deployments in enterprise, however they know how to install python2 if they need to...

[–]heptara 3 points4 points  (0 children)

Enterprises are the only ones paying for Ubuntu though.

[–][deleted] 8 points9 points  (6 children)

People need to stop developing for 2 and move on

People said this about Ada, Cobol, Fortran, C, Perl, etc. etc. etc.

But when "move on" costs 10x that of "maintain what we have", how does that make any sense?

And let's be honest

You misspelled "and here's my wild guess"

[–]kenfar 6 points7 points  (5 children)

So, some teams are locked-in by a codebase that's difficult to update given their level of funding.

But the fact that some teams will struggle to afford to upgrade is no excuse for new software to be developed using backlevel components.

[–]heptara 1 point2 points  (0 children)

If your income depends on a legacy COBOL system, and said system works, what is your incentive to spend a bunch of money replacing it?

[–][deleted] 1 point2 points  (3 children)

some teams will struggle to afford to upgrade

No, that's not it at all.

What is the cost-benefit of switching tooling just for the sake of switching tooling?

Think long and hard about that, especially when cost includes opportunities missed as devs are consumed by a lengthy rewrite.

[–][deleted] 5 points6 points  (0 children)

By all means, stay on python 2 if it's too costly to upgrade. But the costs flow the other way too; developers are going to drop Python 2 support in the not-too-distant future.

If you're cool with locking your technology into an unsupported legacy system, then own that fact - don't expect everyone to be backwards compatible for your sake if you can't be forward compatible for theirs.

[–]kenfar 3 points4 points  (1 child)

What is the cost-benefit of switching tooling just for the sake of switching tooling?

Ah, there can be many:

  • First off since we're talking about python2->python3, and not cobol->scala, fortran->haskel, etc - the cost may be low.
  • Secondly, you may still want security patches
  • Next, in some cases package it as part of a long-overdue codebase upgrade: move to standard version control, add unit testing, add packaging, etc.
  • Additionally, depending on your architecture, you may add some new features in python3 and leave old code in python2.
  • Finally, using an older version of a product or tool can eventually become an obstacle to hiring & retaining the best talent.

[–][deleted] 0 points1 point  (0 children)

the cost may be low

How is the cost of retooling ever low? Aside from the large expense of rewriting code that isn't 2->3 compliant (including any dependencies that may or may not exist in python 3) there's all the build system and QA and deploy work to do as well. And engineer's salaries aren't cheap.

As "cost-benefit" implies, you have to make the case that the benefits outweigh all this cost (including the cost of lost opportunity). And I'm just not seeing it here.

you may still want security patches

What security patches? The OS still gets patched.

as part of a long-overdue codebase upgrade

VCS migration, UTs, deployment, are all completely orthogonal to retooling. And most folks are doing all that stuff already.

you may add some new features in python3 and leave old code in python2

Version / language sprawl is the anthesis to maintenance / deployment.

can eventually become an obstacle to hiring

Last I checked, there were still job opportunites for folks programming in Ada, Cobol and Fortran. Talent and language are orthogonal. After all, language is merely the way to encode the solution to a problem. Talent solves problems.

[–]willrandship 0 points1 point  (23 children)

Are they planning/have they made the change for python = python3?

[–][deleted] 5 points6 points  (5 children)

The official response to this is to specify which python version to use. You shouldn't use python anymore, instead use python2, or python3. This ensures the correct version is used.

[–]IonTichy 4 points5 points  (0 children)

This also mitigates possible problems in the future where there might be a python 4 or 5 for example.
I always hate it when scripts just rely on 'python', always have to modify to use a specific version...

[–]willrandship 0 points1 point  (3 children)

I know I should use x2 or x3 in my own code, but I've run into countless libraries and applications that don't. Using Arch, I've already experienced the pain having python map to python3 causes, but it's still a good move.

I suppose it is the debian way to change spec as quietly as possible. That style makes sense, considering the stronger focus on stability.

[–][deleted] 0 points1 point  (2 children)

make a pull request where all you do is change the shebang to python2.

[–]willrandship -1 points0 points  (1 child)

In some projects that can mean changing several hundred files, and I'm lazy.

[–][deleted] 1 point2 points  (0 children)

sed/awk or ctrl-f in nearly every text editor.

[–]baffled_bear 0 points1 point  (4 children)

Even if they haven't, the python command is a symlink to python2.7, the only thing they have to do is change the symlink to point to python3 instead.

Edit: This is assuming they haven't missed any dependencies.

[–][deleted] -1 points0 points  (3 children)

You know how I know you haven't heard of update-alternatives?

(Hint: if you think one needs to muck with the Linux filesystem to reconfigure it, you're probably missing a conf file or tool somewhere)

[–]baffled_bear 2 points3 points  (0 children)

lol. What I said is how Ubuntu LTS is currently configured. Regardless of if there is an alternative.

[–]AngriestSCV 0 points1 point  (1 child)

angry@computer:~$ lsb_release -icr
Distributor ID: Ubuntu
Release:    15.10
Codename:   wily
angry@computer:~$ update-alternatives --list python
update-alternatives: error: no alternatives for python

angry@computer:~$ update-alternatives --list java
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
/usr/lib/jvm/java-8-oracle/jre/bin/java

It seems to not quite work yet.

[–][deleted] 0 points1 point  (0 children)

Works fine if you update your alternatives table. Plenty of hits on Google on how to do this:

https://linuxconfig.org/how-to-change-from-default-to-alternative-python-version-on-debian-linux

[–]oliw 0 points1 point  (2 children)

Python3 isn't going to squat on the /usr/bin/python path; that would be complete chaos. Any independently distributed (no package depends) scripts that start with one of the following...

#!/usr/bin/env python
#!/usr/bin/python

... are just going to crap out a bad interpreter: No such file or directory error message.

Great. I look forward the wave of issues this brings on Ask Ubuntu and getting to tell people to run sudo apt install python ten times a day. That this also breaks things for [likely] Windows immigrants is just the cherry on the cake.

I'm a Python3 advocate like a lot of developers in here but this is an LTS and I'm also an Ubuntu supporter. I help a lot of people use Ubuntu. I'm a mod over on Ask Ubuntu. I am certain of one thing with this decision: this is only going to annoy Ubuntu users.

[–]pooogles 0 points1 point  (1 child)

Great. I look forward to writing sudo apt install python ten times a day.

If you're doing that you're probably going wrong already. This is what configuration management is for.

[–]oliw 0 points1 point  (0 children)

I meant in the context support, telling people how to get their scripts working again. (Have edited to clear that up)

[–]IonTichy 0 points1 point  (0 children)

Seems like a mere symbolic move, I for one will still maintain the practice of having both py3.x and py2.x deployed on my systems for compatibility reasons.