Why Is the Migration to Python 3 Taking So Long? • Hacker News Board

Re: Why Is the Migration to Python 3 Taking So Long?

#161

Post by avisser » Thu, Nov 14, 2019, 10:18 PM UTC

btreecat wrote: post #112

coldtea wrote: post #69

Earlier quoted context omitted.

> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...

>JS manages to do that just fine How do you define just fine? It's taken us many years to migrate EMCA versions only to have multiple incompatible runtimes. And JS "The good parts" is like 1/10 of the full language so often it feels like a lot of pile on. >as does Java How are them generics?

Now do C#.

You are moving the goalposts and ignoring the fact that Python3 still didn't deliver anything for most users.

Re: Why Is the Migration to Python 3 Taking So Long?

#162

Post by avisser » Thu, Nov 14, 2019, 10:19 PM UTC

kick wrote: post #128

coldtea wrote: post #69

Earlier quoted context omitted.

> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...

Almost everyone hates both Java and Javascript.

And I dislike Python, but that's at best a cool story, bro.

This is a story about language upgrades. Those languages showed how to do it right.

Re: Why Is the Migration to Python 3 Taking So Long?

#163

Post by ogre_codes » Thu, Nov 14, 2019, 10:21 PM UTC

coldtea wrote: post #69

ogre_codes wrote: post #59

Earlier quoted context omitted.

This is backwards thinking. Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. If someone wanted other than the core Python team wants to step up and maintain Python 2, they are free to do so, it's open source. But failing that, expecting the Python team to support the older/ less functional version of the code indefi…

> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...

> And the alternative is cargo cult "newer is better".

Of course it's a "cargo cult" when someone disagrees with you.

> On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...

"Just fine"... that explains why so many shops are dropping support for straight Javascript and switching to TypeScript or CoffeeScript before that. And why Javascript is littered with band-aid libraries like Underscore that are needed to turn it into an effective development language.

Likewise, Java development is slowly being superseded by Kotlin. Java is a mess, there are often 3-4 ways to do simple things and many of them are just terrible for performance.

Re: Why Is the Migration to Python 3 Taking So Long?

#164

Post by ogre_codes » Thu, Nov 14, 2019, 10:24 PM UTC

avisser wrote: post #161

btreecat wrote: post #112

Earlier quoted context omitted.

>JS manages to do that just fine How do you define just fine? It's taken us many years to migrate EMCA versions only to have multiple incompatible runtimes. And JS "The good parts" is like 1/10 of the full language so often it feels like a lot of pile on. >as does Java How are them generics?

Now do C#. You are moving the goalposts and ignoring the fact that Python3 still didn't deliver anything for most users.

This is a hugely American point of view. For anyone who has to deal with unicode on a regular basis, the better unicode support alone is a huge improvement. That's without even looking at the advantages of Async support which offers big performance benefits for web developers—roughly 70% of Python users.

Re: Why Is the Migration to Python 3 Taking So Long?

#165

Post by JaRail » Thu, Nov 14, 2019, 10:25 PM UTC

btreecat wrote: post #112

coldtea wrote: post #69

Earlier quoted context omitted.

> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...

>JS manages to do that just fine How do you define just fine? It's taken us many years to migrate EMCA versions only to have multiple incompatible runtimes. And JS "The good parts" is like 1/10 of the full language so often it feels like a lot of pile on. >as does Java How are them generics?

> How do you define just fine? It's taken us many years to migrate EMCA versions only to have multiple incompatible runtimes.

ECMAScript versions are forward-compatible. Any valid ECMAScript 3 code is also valid 5.1, 2015, 2016, etc.

I'm not sure what migration you're talking about. If you mean using new language features before your runtime targets support them, that's kinda on you. Even so, the ecosystem has tons of robust solutions for supporting legacy interpreters. Most notably, Babel does a wonderful job of transpiling to lower language-version targets.

Re: Why Is the Migration to Python 3 Taking So Long?

#166

Post by tomp » Thu, Nov 14, 2019, 10:30 PM UTC

progval wrote: post #159

erokar wrote: post #36

Earlier quoted context omitted.

The nuisance of having to add self as parameter to every class method, no way of enforcing private methods and the mix between methods on objects and functions in the standard library. OO feels more integrated in e.g. Ruby. About some of the design decisions in Guido's own words: http://python-history.blogspot.com/2009/02/adding-support-fo...

> The nuisance of having to add self as parameter to every class method This was done intentionnaly, because "Explicit is better than implicit". It also has some uses, eg. if you want to do this: class Foo: def inject_bar(self): def new_bar(self2): pass # you can refer to both 'self' and 'self2 here other_object.bar = new_bar It's rare, but it has its uses.

> "Explicit is better than implicit"

Too bad Python breaks this "commandment" pretty much whenever it wants to.

Re: Why Is the Migration to Python 3 Taking So Long?

#167

Post by privateSFacct » Thu, Nov 14, 2019, 10:32 PM UTC

bonzini wrote: post #103

pmiller2 wrote: post #84

Earlier quoted context omitted.

I wouldn’t say 33k is “almost zero.” For me, a single person living in the Bay Area, $33k would pay all of my expenses for a little over 6 months. When we’re talking about this amount of money going to a single individual, I don’t think it’s fair to call it “almost zero.”

I suppose you would have to pay taxes on the 33k you get from a crowdfunding platform.

You would - yes, it's considered income and you may get a 1099-K even if no 1099-MISC in many cases. The 1099-K's have caught a fair number of folks not reporting income they otherwise were getting.

Re: Why Is the Migration to Python 3 Taking So Long?

#168

Post by oarabbus_ » Thu, Nov 14, 2019, 10:38 PM UTC

downerending wrote: post #8

Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…

I ran into an issue recently specific to Pandas and python3 with unicode.

pd.read_excel(filepath) will read an entire dataset even if it contains unicode characters.

pd.ExcelFile() silently drops(!!) unicode rows. The resulting object will simply skip unicode-containing rows (in ANY column) them without even a warning.

For example, if you had an excel file:

word

---

"hello"

你早

"hello"

then pd.read_excel() would give you a dataframe with 5 rows. ExcelFile() on the other hand would return (silently!) a dataframe with only the first two and the last row.

Maybe this is a pandas issue, not a python issue, but it was really horrendous to debug for such a long time only to realize this was the issue.

Re: Why Is the Migration to Python 3 Taking So Long?

#169

Post by avisser » Thu, Nov 14, 2019, 10:39 PM UTC

ogre_codes wrote: post #164

avisser wrote: post #161

Earlier quoted context omitted.

Now do C#. You are moving the goalposts and ignoring the fact that Python3 still didn't deliver anything for most users.

This is a hugely American point of view. For anyone who has to deal with unicode on a regular basis, the better unicode support alone is a huge improvement. That's without even looking at the advantages of Async support which offers big performance benefits for web developers—roughly 70% of Python users.

Fair criticism. But shouldn't you be even more pissed that the Unicode release was botched and we're still talking about it more than 10 years after?

When I upgrade to a new version of C# ... nothing happens.

Backwards compatibility is what made Microsoft the company it is. I think Python deserves all the crap it gets for 2 vs 3.

Re: Why Is the Migration to Python 3 Taking So Long?

#170

Post by Groxx » Thu, Nov 14, 2019, 10:42 PM UTC

Because it's not just syntactic changes, it's implied-semantic changes too. You can't mechanically transform a project and know that it'll work.

And you can't do it gradually, so it's all-or-nothing. (yes, "six" exists, but you still execute one way or another)

And you'll have to change the versions of all your libraries, which is not usually a smooth experience in the Python ecosystem. (this is another place where it's "all or nothing", since six can't help you if your dependencies don't all use it + use it correctly)

---

It's a huge risk with huge cost for already-working, running code. For new stuff, sure, write it in 3, but 2.7 works fine and has the added benefit of being very well understood by this point.