Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Is the Migration to Python 3 Taking So Long?

stackoverflow.blog

Post reply on HN
Print view View original

71–80 of 355 posts

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

#71

Post by _skel »

I recently went through a fairly large upgrade from JDK8 to JDK 11 and it was a bit of a pain -- lots of dependencies to update, etc. But very few code changes were required, and the static type system made it pretty clear when the codebase was broken -- it just wouldn't build. It still took my team several weeks.

Migrating from Python 2 to Python 3 is way worse than that -- code changes are required, and because Python is a dynamic language you may not notice bugs until you actually run the code (or even worse, until after you release it to production and some code branch that is rarely invoked somehow gets called...). In other words, the tooling and the type system are not confidence-inspiring and it's really hard to verify that you migrated without breaking stuff.

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

#72

Post by sweeneyrod »

erokar wrote: post #36
chungy wrote: post #20

Earlier quoted context omitted.

Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.

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 first two of those are explicit design decisions: "explicit is better than implicit" and "we're all consenting adults" respectively.

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

#73

Post by coldtea »

enragedcacti wrote: post #42
CoolGuySteve wrote: post #34

Earlier quoted context omitted.

I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.

I personally really like the self keyword after spending some time reading code in Java where `this` is optional. Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I'm a fan of forcing devs to acknowledge when they are accessing or manipulating mutable object state. Separate from that, I think that would be a much bigger breaking change th…

>Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier.

I don't understand this. Aside from people seeing an OOP for the first time in their life, are they getting confused about where "this" comes from?

How would an implicit "self" a la "this" make it any less understandable where the data come from?

How is passing self making "navigating an unfamiliar code base much easier"? Aside from total newbs who see an OO codebase with an implicit instance variable for the first time?

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

#74

Post by mkesper »

digitalsushi wrote: post #2

I never knew if this was a cynic's answer or truthful, but I was told by my manager at one point that RedHat's OS is superglued to python2 and spends a lot of money to keep python2 in good working order. I highly expect it's a cynic's response and please read it as such until someone in-the-know can retort my post.

There was no way updating the system Python in Rh/CentOS6 from 2.6 to 2.7 as that broke system scripts. You could only use 2.7 in non-standard paths (or Python 3).

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

#75

Post by kstrauser »

goatinaboat wrote: post #63

The 2to3 tool should add .decode(‘utf-8’) to every string manipulation, even better Python 3 should have a flag to make that the behaviour and even better that should default to on. So much effort wasted doing this in a large codebase. And what do you get for it? It’s just not worth it. Nobody actually needs Python 3, it was foisted on them by the developers. What everyone really wanted was Python 2.8.

Speak for yourself. After using Python 3, I can't stand touching Python 2 codebases. Is a given str object an actual text string that's been decoded into a valid charset, or is it an array of bytes fresh from the network / database / file? Who knows, unless you trace back to its point of origin. I personally love that Python 3 says "this is text, and this is some binary data I got somewhere, and they are not the same thing".

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

#76

Post by pfranz »

MaulingMonkey wrote: post #27

We're still waiting for Maya to switch. It's still using Python 2, and Autodesk keeps putting off the transition, partially because it'll break the scripts of all their downstream users.

I think that's partially correct. If you follow https://vfxplatform.com/ it says Python3 was pushed from 2019 to 2020 to allow everyone to upgrade Qt and PySide (which are prerequisites). The reason it was deprioritized in previous years were similar transitions like C++14, gcc, etc.

I've been meaning to dig into Maya, Houdini, Nuke's Python 3 transition plans. I know Houdini will offer a Python 3 option with Houdini 18 (shipping in the next month or so).

I don't think the reason was because of downstream users. Python 3 was an inevitable change. Previously, they swapped out PyQt for PySide which wasn't a forced change, but required everyone to update their Python scripts.

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

#77

Post by dang »

alexhutcheson wrote: post #15

[copying comment from an older HN thread, not speaking on behalf of any employer, opinions my own] I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current too…

Please link to previous comments rather than copying them. Copy/paste isn't good for fresh conversation: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

It's a great comment otherwise.

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

#78

Post by fireflash38 »

coldtea wrote: post #73
enragedcacti wrote: post #42

Earlier quoted context omitted.

I personally really like the self keyword after spending some time reading code in Java where `this` is optional. Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I'm a fan of forcing devs to acknowledge when they are accessing or manipulating mutable object state. Separate from that, I think that would be a much bigger breaking change th…

> Having to reference self makes it more clear where data is coming from and makes navigating an unfamiliar code base much easier. I don't understand this. Aside from people seeing an OOP for the first time in their life, are they getting confused about where "this" comes from? How would an implicit "self" a la "this" make it any less understandable where the data come from? How is passing self making "navigating an…

I believe the original commenter was more referring to the lack of 'this' usage in Java.

So instead of having:

    this.x = y
People tend to do:

    x = y
Which isn't always the most clear that it's referencing an instance variable rather than a scoped variable, especially if you see it midway through a method.

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

#79

Post by erokar »

sweeneyrod wrote: post #72
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 first two of those are explicit design decisions: "explicit is better than implicit" and "we're all consenting adults" respectively.

Most things in a language are explicit design decisions. Doesn't automatically make them good decisions.

Actually Python is one of my favorite programming languages, probably the language with the closest mapping to how I naturally think about a problem. I really like it. But I'm also willing to admit it has some warts, as does any language.

Post reply on HN