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

51–60 of 355 posts

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

#51

Post by compiler-guy »

lasermike026 wrote: post #18

Management wants new features not porting. They will only port when they absolutely have to.

As well they should. No one uses Dropbox today that didn't a couple of years ago because it is using Python 3 instead of Python 2.

The migration is financially negative in the short term, and very clearly so. It might be financially positive over the long term (due to easier maintenance and higher performance), but that is definitely maybe. Especially for an app that is otherwise very stable.

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

#52

Post by criddell »

mistrial9 wrote: post #39
war1025 wrote: post #24

Earlier quoted context omitted.

As a member of a team hopefully nearing the end of the python3 migration, this is exactly correct. The unicode switch is a nightmare in terms of having to go through and double/triple check everything and still get it wrong half the time. Particularly when it comes to moving data over the network. The big selling point for Python3 finally came with the built-in async support, but we've been using Twisted for a decade…

right - and .. for the one that posted on YNews to say "yes we did it" there are of course others who do not post on YNews and did not do it.. There is nothing wrong or bad about Python 2.7, in fact, its great and works as advertised.

> works as advertised

That's kind of a low bar. An IBM PC running MS-DOS 3.3 works as advertised but I wouldn't want to use one today. Except for the keyboard.

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

#53

Post by sbierwagen »

privateSFacct wrote: post #40
hermod wrote: post #23

Earlier quoted context omitted.

With respect to async, I'm partial to trio [0], which is a spiritual successor to curio [1]. The model is similar to Golang in many ways, e.g. communication using channels [2] and cancellation [3] reminiscent of context.WithTimeout, except that in Golang you need to reify the context passing. The author has written some insightful commentary on designing async runtimes [4] and is actively developing the library, so I…

I was curious about [5] The link to support requests (which is a great piece of software) is here: https://cash.app/$KennethReitz Note: This is NOT a charitable donation, it is a gift to an individual. These are not tax deductible under US law. Njs has a long attacking blog post saying this needs to go through PSF (huh?) and that they should be getting most of this money not the person the funds were directed towards…

It's always amazing how adding a little money to the mix makes people lose their minds. NJS was working for free. KR raised some money from large businesses, then told NJS to keep working for free. NJS retroactively discovered that working for free is stupid, and tried demanding all the money NJS raised. This didn't happen, of course, since he had no leverage at all on NJS besides complaining online.

The takeaway here appears to be "never work for free". If NJS has worked on his own project, controlled by him alone, this wouldn't have happened. If you donate a bunch of work to an open source project, then... well... the source is open.

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

#54

Post by carapace »

mxcrossb wrote: post #33
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…

On the topic of not enough carrot, I’m curious how impactful the end of support for python2 will be. How many programs stuck in python2 are encountering bugs in the runtime?

I actually find this aspect of the whole thing exciting, perhaps paradoxically. Now that Python 2 is static the runtime can become asymptotically bug-free. Meaning that, if you only change it to fix bugs (as opposed to introducing new syntax|semantics) it's going to approach perfection.

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

#55

Post by carapace »

upofadown wrote: post #28

Py3 is for all practical purposes a language fork of Py2. So it doesn't really make sense to talk of a "migration". If Py2 becomes unworkable somehow then people will rewrite stuff. Some of it might even be in Py3. Considering all the stuff that is written in Py2 I really don't see it being out and out abandoned. That wouldn't really make any sense. With computer languages stuff never goes away.

Py2 is the new Fortran, I like to say.

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

#56

Post by wnissen »

Animats wrote: post #48

First off. Python 2.6 and 2.7 supported Unicode just fine. I had a large all-Unicode system in Python 2.6. You had to write u'word" to get a Unicode constant, and use a "unicode(s)" function here and there. Also, the part that remained "compatible" was that "str" remained an array of bytes, even though there was also a type "bytes" and a "bytearray". Early Python 3 was hell for conversion. The syntax was changed for…

They still did stuff that makes no sense, to me, like not supporting `iteritems` on dictionaries and `xrange` on sequences. Or using `str` to mean bytes? That would have been possible to make backwards compatible until Python 4. At this point, does anyone think there will be a Python 4?

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

#57

Post by dfinninger »

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…

To your last point, check out Dataclasses[1].

    @dataclass
    class Foo:
        arg1: str
        arg2: int
        arg3: int = 5  # default value
I use them a lot in my 3.7+ projects. It helps reduce the boilerplate for typical classes. (Where for me, typical classes are a 1:1 mapping of inputs to attributes)

And if you need to compute some values at object initialization, then they have a __post_init__() hook you can use [2].

[1] https://docs.python.org/3/library/dataclasses.html [2] https://docs.python.org/3/library/dataclasses.html#post-init...

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

#58

Post by dfinninger »

timw4mail wrote: post #38
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.

My experience with Python is a little lacking, but doesn't the self keyword mean the difference between an instance method, and a static method? Rust does the same thing - with self, it's an instance method, without, it's a static method.

Python has an "@staticmethod" decorator you can put on a function inside of a class definition. Then you don't need to pass "self" as a first arg.

https://www.geeksforgeeks.org/class-method-vs-static-method-...

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

#59

Post by ogre_codes »

semiotagonal wrote: post #13
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 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?

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 indefinitely is unrealistic. Corporate owned languages have even shorter lifecycles for exactly this reason.

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

#60

Post by WorldMaker »

zabzonk wrote: post #37
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.

To be pedantic "self" is not a keyword.

Worse than that not being a keyword, `self` isn't special at all, it's a naming convention that can be freely broken. Python codebases using `this` instead of `self` exist. Codebases that mix the two depending on who wrote which method in a class exist. I believe I saw `it` used once somewhere as the name for that parameter. I'm sure there are codebases with even crazier horrors for first argument names in class methods out there in the depths of corporate machines.
Post reply on HN