Hacker News Reader

Comment by chimeracoder | Hacker News Reader

> Python 3 breakage and async turned out to be prescient, fantastic decisions.

The jury is still out on the Python 3 decision, to be honest. Heck, Python 2 is still officially supported until 2020.

Python 3 adoption is increasing, but the instability and breakage that it introduced caused a lot of knock-on effects throughout the Python community that held it back and hindered its adoption and mindshare. It'll take a while before we can really say whether the long-term gains will make up for that.

View on HN

> The jury is still out on the Python 3 decision, to be honest.

It's not. Python 3 has overtaken 2 and there is no stopping migration to it now. Python 3.7 is a lot better than 2.7. Just on memory use alone, 3.7 is massively better. Sure, there will be some hold outs on 2.7 for a long time. That's fine.

Also, this is not the say that migration from 2 to 3 was handled well. It wasn't. Python 3.0 should have had backwards compatible features like allowing the 'u' string prefix. Indexing byte strings should have returned length one byte strings. Byte strings should have supported at least a minimal amount of %-style formats. Etc.

That has all been mostly resolved and is in the past. Mistakes were made because, shock, the Python core developers are not perfect and didn't foresee all the migration issues. However, there is no way that we are going back and reviving the Python 2.x branch.

How much momentum was lost in the transition though? I know that with the pain of 3 at the time a lot of people started looking at languages like Go or even Scala.

Python currently still 4th at https://www.tiobe.com/tiobe-index/ . As the most popular scripting language on there by some margin, I'd say they're still doing pretty well.

It was touch and go for a couple of years there but yeah, Python 3 is now well and truly over the hump.

The Python 3 Readiness Project now lists [341](http://py3readiness.org/) of the 360 most common packages as Python 3 compatible.

Even that's underselling it really. For example it lists BeautifulSoup as not converted, but the link goes to BeautifulSoup 3.2.1. However, BeautifulSoup4 works great on Python 3. And for MySQL there's mysqlclient and several others, and since database packages usually follow PEP 249 pretty closely its very easy to switch. So in reality, rather than 341/360, its more like "everything worth converting has been converted." Or just "everything" for short.

false imperative => "Python 3 has overtaken 2 and there is no stopping migration to it now. "

this shows a superficial, almost entertainment-industry sort of view of a software development lifecycle..

in the latest Ubuntu Bionic with apps, building right now on a local machine, I see 143 python-xx packages installed and 43 python3-xxx ..

saavy package authors use import future and six to side-step the whole issue, while core maintainers struggle, and outsiders invoke a mob voice

Python 2.7 for LTS

That's not the point of the person you're responding to. They didn't say that the transition didn't happen. They said it's not yet known if it was worth it. All you're saying is that it happened.

I'm saying it happened and Python 3 is the language I want to use. If you don't do Python 3, you either keep the error prone str/unicode string model or you dream up some way to evolve to a better model. Would some mythical version of an evolved Python 2.x be better than what we have? I mean, how to argue against that? I haven't seen anyone propose a workable migration plan. Python 3.7 is better than 2.7.15 and better than 'tauthon'.

Python 3 avoided becoming what Perl 6 has. That alone is a victory.

Is there even a "production ready" version of Perl 6 yet? It has to be the worst example of production hell for a computer language in history. It's the poster boy for the second system effect.

There has been a production ready version of Rakudo Perl 6 (https://perl6.org) since Christmas 2015. It has been on a monthly release cycle for years, and a 3-monthly release cycle for Rakudo Star, the "user" distribution (with some bells and whistles added).

Cro (https://cro.services) is a set of libraries for building reactive distributed systems. Comma IDE (https://commaide.com) is an IDE for Perl 6, based on the JetBrains IDEA platform, now in (paid) beta.

If you want to keep up-to-date on Perl 6 development, check out the Perl 6 Weekly (https://p6weekly.wordpress.com).

Well, many embedded developers will never move beyond C89 unless forced to do so.

Meanwhile C22 work is ongoing.

> Well, many embedded compilers will never move beyond C89 unless vendor is forced to do so.

FTFY

Not really, many of those developers do have C99 compilers with partial C11 support at their disposal.

There are almost no vendors left offering C89 only compilers.

I'll probably never switch for personal use. The print statement change is intolerable to me. It would have cost them nothing to just leave the old syntax in. It's supposed to be a quick and convenient scripting language and they're actively working to make it more verbose and less convenient. I also still don't like not being able to use "string" objects as dumb byte containers, like I do with an IRC bot that doesn't crash with an encoding exception trying to write IRC control characters into a text file. Yes, I know I can work around that wrapping everything up nice and pretty to tell python "this isn't a real string it's okay you don't need to throw an encoding exception ssh." I just don't think that's good design.

Syntax regularity is infinitely more important than scripting convenience.

Button regularity on your keyboard is infinitely more important than ergonomics too, right? Anything but a grid of equally-sized squares must be wrong by virtue of aesthetics. Spoken language too: let's eliminate all contractions because they reduce regularity. Let's also make all the speed limits in the country equal at 20mph, because regularity is infinitely more important than convenience.

You should be supporting return being made into a function too, right? That would be much more regular.

Reminder that a guideline of python was supposed to be "practicality beats purity" which is in stark contrast to the changes to print and strings. [1] Reminds me of the gradual shift of the message on the wall in Animal Farm from "four legs good, two legs bad" to "four legs good, two legs better."

1: https://www.python.org/dev/peps/pep-0020/

Are you fingers equally spaced square shape manipulators?

I don’t support having return at all. Statements that are not expressions are a mistake.

Syntax irregularities are anti-practical.

Try Ruby.

Aw, alright then.

Reply on news.ycombinator.com