Here's the talk https://www.youtube.com/watch?v=skYBOXE02OQ

Periodically I check my requirements.txt with https://pypi.python.org/pypi/checkmyreqs, but there's usually at least 7 or 8 minor packages and 2 or 3 major ones that are unsupported.

I don't really mind moving my own code to python 3, but I'm loath to move working library code.

Archlinux defaults to python3 (the default python is just a symlink), and most of the things are pretty good, though there are plenty of python2 related problems, and problems because of the devs patching the upstream distro too much...

All in all it's quite okay, and definitely on the right path.

Ubuntu is one the most deployed server distributions of linux, and one of the most battle tested. While this post isn't meant to criticize python 3 (I think the language is perfectly fine as is), it's meant to criticize the ecosystem, where one of the most deployed distributions doesn't work.

>This has very little to do with Python 3.

Which is the point of the article and P3's biggest problem: All the things surrounding it.

The people behind Python seems desperate to push everybody to Python 3, mostly by telling people how much better Python 3 is than Python 2. But the thing is, that doesn't matter when the environment surrounding Python 3 is considerably worse than for Python 2.

If you ask me to switch OSes in order to do something, there has to be a very strong value proposition to get me to risk the time.

Using Anaconda solved all this for me.

It isn't being used to draw that conclusion. The article starts with that premise and uses an anecdote to illustrate one reason why. In marketing and customer service, the plural of anecdote may not be data but it is is a broad trend.

I feel like the balance has tipped in the past six months. I started my current project two years ago and stuck with Python 2 because I was concerned about library compatibility.

The Python 2 standard library is now showing its age. Limitations with the multiprocessing module on Python 2 drove me to look into the possibility of switching to Python 3 and I was pleasantly surprised to discover all ~45 packages my project depended on had been ported (through caniusepython3.com.)

Porting to 2/3 compatible code with python-future.org turned out to be fairly painless so I expect to make the change soon.

The transition has been a painful one, but I'm sure that these sort of problems will feel a thing of the past in a year or two.

Check out https://python3wos.appspot.com/ . The majority of major packages have been ported over. Most of the bigger stuff is often run independently and not actually imported by other code (sentry, supervisor, ansible... to name a few).

That situation has improved. For a long time, the libraries for a MySQL database and for parsing HTML were completely different on Python 2 and 3. Now, at least, there are libraries for those operations that work on both platforms. It's taken years for that to happen, though. I'm considering porting a production Python 2.7 system, and it now looks feasible to convert it to using different packages on 2.7, then convert to Python 3.x.

Agree with the other people replying. I tried twice in the past to switch but always got stuck at some important nonported package. Recently, however, I jumped in and was mesmerized that i) most packages worth installing are already ported to py3, and ii) py3 has some sweet things that I didn't got with 2.7 that make it worth it.

That may have been the reason awhile back, but it's not the case for the vast majority of projects these days. Though the stigma may still be a major cause for lack of traction.

Perhaps the title should be altered. My main argument is that the ecosystem around python3 is what's holding it back. I think the language itself is perfectly ready, and even most major packages have been ported over.

The daily builds of the 15.04 alpha may be on the mirrors but what he meant was cutting-edge stable. Had he used an unstable daily build, his arguments would have been much less relevant.

True, it's an incredibly personal and situational post with him using the word "me" throughout. The title choice is just really poor it seems.

Although I'm someone who doesn't develop in python, I have toyed around with the packages and versions for dependencies for other projects and tools I use. At first I assumed that "latest is greatest" but recently came to understand that it's not the case as far as practicality is concerned. Perhaps it is involved with the rather irritating versioning (python3, pip3, etc. - I've found the same thing to be true on archlinux), but I think a lot of it is definitely as somebody else said above, the lack of updated libraries.

There was no moderation on this title, nor on the post in any way.

    > In the way of purpose and design, Rust has next to
    > nothing in common with Perl, Ruby, Python, etc

This is the top-rated reply to my initial comment, so I'll try and fill in the gaps.

People choose Python instead of Perl because - and the reason they give may be different, but it comes down to the same thing - there's one RIGHT way to do everything. There's a _pythonic_ way to do everything. PEP 8 not only exists, but people take it _seriously_. Python code is predictable, and while people will bring different engineering approaches to bear on certain problems, good Python looks the same at every company.

Go is the Next Level Up of that. "go fmt" and "go vet" are baked right in. The language is small, and explicitly leaves out certain constructs in order that there is one, clear, obvious way of doing things. In short, Go code is meant to be predictable, and good Go code should look the same everywhere.

If you want to spend your time thinking about the problems, solving the problems, and zero time decorating your art, Python and Go are for you. They are the International Style or architecture, they are Brutalist languages, and that's not only OK, but it's a fundamental part of their success.

Me? I like Baroque.

I like my sigils, I like combining functional and imperative constructs in ways that I think look beautiful as I write them. I like cute tricks, and coworkers can see code I wrote because I come back to my favourite beautiful and intuitive idiomatic patterns over and over again, just as I can identify their code for what they do. I don't think `map` is a dirty word, and I love starting with a list and whittling away at it, sorting it, reshaping it, exercising the differences between lists, arrays, hashes, and the coercions between those.

You go to the back of the Camel book, and it gives you four different code styles, depending on what you're optimizing for. Perl Best Practices is the most controversial book ever written.

I'm still a Rust baby, but I'm telling you, it TASTES like Perl. The language "features" thing is reminiscent of someone suggesting you shouldn't buy an iPhone based on processor speed.

That isn't the first time such a comparison has been made, and the people making it are always remarking more on the culture surrounding the language than its implementation details (not that the latter are irrelevant, but Python certainly could be a Compiled Language™ if Guido so chose). The takeaway here is that both Go and Python codebases lend themselves to team efforts between early contributors and new arrivals, because the set of idioms you'll find is very consistent from one codebase to the next. This promotes a certain confidence in teams working on very large projects, as well as tools that must be maintained for a long period of time. It's a hard thing to measure. You certainly won't identify it just by asking what features the language has.

>Python3 was never intended to be a "one way to do everything language".

Python's motto is "There should be one-- and preferably only one --obvious way to do it." - its not meant that Python should be the only tool, but that written python code should only have one have common implementation. (https://wiki.python.org/moin/TOOWTDI)

Golang also seems to share the same ideal when it comes to written code.