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

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

#111

Post by takeda » Thu, Nov 14, 2019, 9:04 PM UTC

SignalsFromBob wrote: post #88

semiotagonal wrote: post #13

Earlier quoted context omitted.

I wonder how many people feel that migrating to Python3 would have been worth doing in the absence of being forced to do so. Dropbox invested three years of work, actually hired Python's creator, and are still not done. What are they getting out of it that they wouldn't have gotten if Python2 simply had been maintained?

I suspect that someone, or a group of people, will step up to unofficially maintain Python 2 for the foreseeable future. It's clear that there are a lot of people using it that either can't easily migrate or are unwilling to do so for the various reasons already discussed in this thread.

I'm sure that for the right money you can find someone.

Don't forget that that person/organization would not only have to maintain python but also all the packages that you will be used.

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

#112

Post by btreecat » Thu, Nov 14, 2019, 9:04 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...

>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?

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

#113

Post by alexhutcheson » Thu, Nov 14, 2019, 9:05 PM UTC

kevin_thibedeau wrote: post #49

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…

The way to start a migration is to first get the 2.7 code as forward compatible as possible. Bring in the future imports. Make sure equivalent iterators are used where 3.x mandates them (xrange, iterkeys, etc.). Make sure Unicode is managed correctly on I/O. Explicitly call out truncating division. This doesn't require parallel testing. These all improve the quality of 2.x code even if you never make the leap to 3.x.…

It requires parallel testing to make sure the files you've "future-proofed" aren't accidentally un-future-proofed by later commits.

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

#114

Post by gpderetta » Thu, Nov 14, 2019, 9:06 PM UTC

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...

FWIW, I wish 'this' were explicit in C++.

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

#115

Post by twblalock » Thu, Nov 14, 2019, 9:07 PM UTC

LIV2 wrote: post #86

_skel wrote: post #71

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 Pyt…

Will this will make people less likely to use Python in future for some projects? I'm no developer or manager but I figure there'd be a thought in the back of my head thinking "what if we need to rewrite this all again for the next major release"

What I've been seeing is people using Python 3 for new projects but leaving their older projects on Python 2. As a result of that, Python 2 will continue to be supported internally at a lot of companies, even though it is "officially" end of life. Nobody wants to rewrite the stuff they finished years ago that is now in maintenance mode.

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

#116

Post by takeda » Thu, Nov 14, 2019, 9:08 PM UTC

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...

first is a design decision, felt weird at first but after time I kind of like it, there's less magic behavior happening.

The second is not true, if you add methods with double underscore (also design decision) they do behave like private. The real method name will be randomly generated so you won't get conflicts, and you can still access it for debugging purposes.

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

#117

Post by UptownMusic » Thu, Nov 14, 2019, 9:10 PM UTC

Simple. Python 3 is theoretically better but not in fact better, at least for most applications of Python.

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

#118

Post by gowld » Thu, Nov 14, 2019, 9:10 PM UTC

uranusjr wrote: post #89

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...

I’ve seen a lot of people taking issue with the self argument. Am I crazy to actually love it as a feature? I pulled out a lot of my hairs when I first started OOP (Java) trying to gork `this`, and I remember myself thinking “why didn’t everybody just do this” when I saw how Python declare methods. And I still think that’s a good idea now. So much easier to keep my sanity than using JavaScript’s bind.

What's weird is that it's half baked

   def foo(self):

instead of a more logical:

   def self.foo():

to match the calling syntax.

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

#119

Post by gowld » Thu, Nov 14, 2019, 9:11 PM UTC

ForHackernews wrote: post #107

smacktoward wrote: post #83

Earlier quoted context omitted.

There's a fine line between "explicit is good because it means how things behave is obvious" and "explicit is bad because it means typing the same boilerplate over and over again." Not saying Python fell on the wrong side of that line, just that it's an easy line to end up on the wrong side of.

You're free to use `_` (or whatever) instead of `self`, if you find `self` to be much repetitive boilerplate. It's only a convention.

Sadly the linters went for `self`.

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

#120

Post by joshuamorton » Thu, Nov 14, 2019, 9:11 PM UTC

test7777 wrote: post #100

joshuamorton wrote: post #93

Earlier quoted context omitted.

Please no! Text is text. Bytes is bytes. Convert to the correct form on input boundaries, and that's it. Don't switch back and forth internally, it's overly complicated, error prone, and slower.

unix pipes (stdin, stdout) are bytes, files are bytes, filenames are bytes. yet, for some reason python3 thinks al of those are text. its not the coders that are wrong, it is the language.

kstrauer is right, but I'll elaborate and say that places where you are interfacing with Unix threads are input boundaries, so having the programmer make a choice makes sense. Arbitrary switching within a program does not.