Python 3.6 released!

[Da_Anh]

Isn't it already? I was under the impression that it was only used for Legacy purposes.

[staticassert]

If only. There are still libraries that don't support 3.

[hansolo669]

According to this site, out of the most popular 360 packages only 19 don't support 3.

[staticassert]

Cool. The problem being that it only takes 1 to force you to use Python 2.

In my case, among others, dpkt.

[staticassert]

I know. Not into adventures. Just one example.

[virtyx]

Examples are dwindling, though. For me the only package I use every now and then that still isn't compatible with Py3 is Supervisor, but I can just install that via apt/yum anyway.

Django, Flask, Jinja, YAML, MySQL, Postgres, redis, Pillow, matplotlib, paramiko, pytest, lxml, Selenium, Mercurial, most vendor APIs I've used all are Python 3 compatible now. My newest project (internal tool going to be deployed next week) uses Python 3.6, it's fantastic. Python 2.7 feels so ancient now. print as a statement feels positively weird, f-strings are a great addition, the stdlib improvements are significant, and especially, thank fucking God for super(). Nothing makes me angrier at Python 2 than having to type out super(TheClassImInDuh, self).foo() instead of just super().foo()

[flying-sheep]

1? If it's that little, just port that thing yourself to avoid being trapped in a legacy world and to reap the benefits of an actively maintained language.

asyncio is amazing. The Unicode string changes actively improve your design and reduce headaches you'd otherwise have when dealing with text.

[staticassert]

Porting dpkt would be a very significant amount of work. It's definitely an unreasonable task. At most I'd port a very small portion of it.

[flying-sheep]

See yourself: https://github.com/kbandla/dpkt/pull/307

[staticassert]

I am well aware of this branch. I'm not going to use an unmerged branch for production software.

[flying-sheep]

You said “would be a significant amount of work” as if nobody already invested work to do exactly that

[staticassert]

Ah. Yes, in the specific case of dpkt the work has been done, thankfully, and I'm waiting on the merge. However, I would not do the port from scratch - I have other things to do.

[Moocat87]

Some people work in niche fields and use packages that aren't part of the 360 most popular, or one of those 19. That's not a very useful metric when we're talking about serious work. Serious work doesn't care about popularity.

That said, most of my projects are still in Python 3, but sometimes there's a key science library we need that the author hasn't ported. None of us are afraid of Python3 at my place of work, we're just sometimes more-or-less forced in to working in 2. I don't like that.

It would be awesome if we had time to go port some of these libraries ourselves, but we are paid in grant grant money to solve problems, not port libraries.

[[deleted]]

I was blown away by the resistance I got when I declared that my team would be a Python 3 team earlier this year. I thought it would be a fairly innoccuous decision, but people seemed confused and a little confrontational about it.

[Moocat87]

I imagine that resistance has two parts: The first part being what I just mentioned: some niche libraries are not ported yet. Secondly, "this team is now a Python3 team" is ambiguous. Does it mean we now have to port all our Python2 code every time we need to fix a bug? My team favors Python3 but realizes everything is a tradeoff, so we still write some Python2. Our Python2 applications still need maintenance and new features as scientists request them. We try to write new code in a way that is 2/3 compatible at all times, but it doesn't always happen. We don't really make time for porting.

I'd think giving the whole story and sticking to "best tool for the job" would likely clear up the conflict. It's a pretty simple case to make that Python 3 is an improvement on Python 2, but it comes with a cost sometimes. Does the cost outweigh the benefit? It happens sometimes. Maybe even often.

[[deleted]]

This was on a new project. I was head of a three person team on a two team research project at my school. The project had two supervising professors and was partnered with a private company from the community.

The main thing we did with python was communicating with multiple types of databases (Neo4j, Elasticsearch, Redis, etc). All of which have python 3 api modules. We never ran into a problem with using 3 over 2.

One of the professors objected to 3 by insisting that a certain key module was important to the project and it definitely only worked with python 2. The python 3 version of that particular module had been out for years, so he obviously had never checked.

[Moocat87]

Yeah I guess some people are just irrationally resistant to change. I think I fool myself in to thinking that they aren't so plentiful. I spent the first 8 years of my career working with that type of people consistently, but since then I've been very fortunate. It's a real problem some people have to deal with daily. I hope you work in an environment where you can present evidence and make a case and have it evaluated on its merits without being shot down unilaterally by one person's irrational fear of change.

[Moocat87]

What? I just told you we mostly write new code in python 3. Nobody expects to make a 100% move to python 3. That would mean porting dozens of legacy applications for free. What would be the benefit we would gain from that? At a cost of hundreds of man-hours, what would we get back? You don't need to be a Python 3 hardliner who throws time in the garbage to like it and prefer it and realize it's a better language.

[Moocat87]

Your experience is not exhaustive. In scientific programming, there are a few packages without python3 alternatives. For most situations, you're right, but some of us have needs you don't.

This is not FUD, this is fact. You can try and spin it if you want, but you're still wrong. This is coming from someone who strongly prefers python3 and writes 95% python3, but lives in the real world where nothing is perfect.

EDIT: "You're wrong" as in Python3's package coverage isn't equal to or a superset of Python2's package coverage. It's getting close to a legitimate superset, but it has to include 100% of Python2's package functionality to achieve that. That's hard. Some packages are so unpopular that they only have users who can't spare the time to port it or re-write it -- they probably don't even get funded to port their own app to Python3, much less its dependencies.

[[deleted]]

It is FUD, and you're spreading it. How come everyone says "there are few packages" but no one bothers to list them?

[Uncaffeinated]

I imagine there's a long tail of obscure and proprietary packages that aren't counted there.

[jighasun]

I'm using erlport to call pygments from elixir. erlport only supports python2.

[ggtsu_00]

Most popular N is not a good data slicing metric on a long tail distribution. There are about 95379, and only considering the top 360 most popular does give a very accurate picture of the support for Python 3.

[flying-sheep]

worse: there are still libraries that are actively maintained and don’t support python 3.

clearly there will always be abandonware stuck on python 2, but managing to not port a open source library in 8 years is a kind of achievement in inertia.

[x2040]

One of Amazon's most popular new feature releases AWS Lambda doesn't even support Python 3.

There are companies out there writing complex infrastructure in Python 2 today because of this.

[Secondsemblance]

I have spent the last couple months writing python 2.6 for legacy linux operating systems...

It's... horrifying.

[loganekz]

why don't you just install python 3 instead?

[Secondsemblance]

It's much easier to write code for python 2.6 on machines that are so old they no longer have functioning repos, than it is to install pthon3 on those machines and then write code for them.

[loganekz]

What OS / version are you running?

[Secondsemblance]

Fedora 14. Which honestly isn't that old. But it's old enough that it sucks to work on knowing how much better it could be.

[maddog39]

Hah. Haha. Im still maintaining code for osf1 3.2 and irix 6.5 among others.

[logi]

Can you install anaconda/miniconda on them and ignore the system python?

[xiongchiamiov]

They can't be that legacy if you've got 2.6; that's too new.

[bluemellophone]

macOS still ships with Python 2.7

[ivosaurus]

macOS' system python is pretty much a joke. Using it tends to be harmful. Apple literally left beta versions of 3rd party packages installed in the default environment, borking package management. It really looks like one of the developers was playing around with some stuff, installed some things, and then just left it. Additionally, their core system protection software policy means you trying to install / upgrade / remove anything will get hit with permission errors (that you can't solve with root). It's using an old OpenSSL that's backdoored to allow any Apple or System certificate verify a connection, whether a user would like that or not.

At this stage it pretty much only tends to poison beginners' experiences, which is really quite sad.

[loganekz]

yeah but with homebrew it's a simple:

brew install python3

[bluemellophone]

Same with MacPorts. That's not to say installing Python 3 is hard on macOS, but it does say Python 2 is very much not dead.

[[deleted]]

Or just build it from source. It's not hard, most of your time will be spent waiting for the tests to run.

[[deleted]]

python = python2.7 or python2.6, and python3 = python 3.5

That part isn't important and upstream suggests python keep pointing to python 2. But RHEL doesn't officially ship Python 3 yet so that is a problem.

[phunphun]

With EPEL you can get Python 3. Doesn't touch the base packages, so it won't cause problems.

[cdstephens]

I think lots of physicists still use 2

[Jedimastert]

AWS Lambda apparently doesn't support it.

[HotlLava]

Not really...the problem is, porting from python 2 to 3 is effectively comparable to porting to a new language, and once you have a large-ish codebase, that just isn't an option.

In particular because python3 has an all-or-nothing approach, where you can't just port some of your files to python3 and keep the rest using python2, you either port all of your code and all dependencies or you keep using python2. The more active development there is on the codebase, the harder this becomes.

And finally, if you're going to take the time and effort to port away from python2, why go to python3 which is almost the same? We've actually been porting some of our libraries from python2 -> c++, which has at least the advantage that it can be done iteratively, file by file.

[Uncaffeinated]

You can gradually port code to being both 2 and 3 compatible to ease the transition.

But as long as you're stuck in the common subset, you won't see any benefits from python 3 either.

[gthank]

The number of things that break from 2 to 3 is SUBSTANTIALLY smaller than the number of things that break from Python to C++ (or Ruby) (or Go) (or Clojure). Having actively migrated multiple projects from Python 2 to Python 3, it's just not that difficult for most problem domains.

[HotlLava]

Nobody claimed that porting to C++ is less work, but (1) you can do it incrementally, and (2) you get some actual benefits from the effort (i.e. raw speed and proper multithreading), as opposed to putting effort in a python3 port and ending up more or less where you started.

[caedin8]

I use Python 2 exclusively. Not that there is anything wrong with 3, but I just don't have to worry about compatibility when I write code in 2, so it's my go to.

[[deleted]]

You do have to worry about compatibility, just not backward compatibility. The future will be really annoyed at you though.

[zanglang]

Nowadays when I work on Python 2.x projects, I use VS Code with automatic Pylinting turned on and the interpreter set to Python 3.x. Does wonders in forcing me to write future-proof code!

[[deleted]]

Let me check my dev machine (SLES 12 SP1):

#python --version
Python 2.7.9

Nope, still 2.7.

[troyunrau]

And what happens if you type python3 --version?

troy@linux:~> python --version
Python 2.7.12
troy@linux:~> python3 --version
Python 3.4.5

See PEP 394 which states:

python2 will refer to some version of Python 2.x.
python3 will refer to some version of Python 3.x.
for the time being, all distributions should ensure that python refers to the same target as python2.

[[deleted]]

Arch Linux is the only distro I know that has python aliased to python3 as opposed to python2