Live data from Hacker News

Why Is the Migration to Python 3 Taking So Long?

stackoverflow.blog

101–110 of 355 posts

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

#101

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.

And they both use actual Fortran :)

  $ python3
  Python 3.7.4 (default, Sep  7 2019, 18:27:02) 
  [Clang 10.0.1 (clang-1001.0.46.4)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import numpy
  >>> 
  [2]+  Stopped                 python3
  $ lsof -c Python | sed -n "/fortran/s/$USER//gp" 
  Python  35190   txt    REG    1,4  1550456 12887664541 /Users//Library/Python/3.7/lib/python/site-packages/numpy/.dylibs/libgfortran.3.dylib

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

#103

Earlier quoted context omitted.

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…

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.

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

#105
post #86
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"

I don't think it will make people less likely to use Python overall, but for certain categories of projects there are some things that are just done better in other languages. Both Java and Go for example have specific programming language constructs and contracts to ensure that codebases can move from version to version easily and I do not feel like there is a dynamic/untyped language that really provides that same level of stability. The ones that do get close to that are the ones that are extremely small in scope and are not in the same class of batteries included language, and because of their small scope they have a general limit of change.

At a certain point this sort of compatibility/forward motion of a codebase through big language revisions is something that has to be designed as part of the language in either being able to break it down into small enough chunks to chew through in pieces (updating a submodule with the updated language without affecting anything else), completely transparent to the code being run through it (this happens for compilers for C for different standards), or to have a version to version automated rewriting mechanism that is so reliable the outcome of the automated tool is not in question (tools like Go's gofmt). Python in my opinion only has partial solutions to all of those answers so it turns into a lot of hand work.

So while there are other languages that may do other things better there are still a class of programs that are very effective to write in Python, and that's plenty enough reason to keep it around. Do not forget that Python 2 was released in 2000 and Python 3 was released almost a decade later. The general time scale makes worrying about the next release for many people, but for people who do they start considering other languages because that's important to them.

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

#106
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…

> Python 2.6 and 2.7 supported Unicode just fine It did, but in a way that chainsaws support sculpting just fine. Technically possible. Very advanced people will know how to handle it. Everybody else is just going to injure themselves randomly. Most people writing py2 got the text/binary processing working on accident. Things appear to work until you throw actual Unicode into parameters and then nobody knows what hap…

> Now they're told immediately

Or so you wish, it's not necessarily true though. It's just as likely to pass through gibberish without blowing up.

I have a tiny relay service written in Django that lets me pass messages between my phone and home computer, that I recently upgraded both the python and Django version. The service is only two views of about 3 lines each - and a unicode conversion bug crept in such that it stored "b'text'" in the database instead of "text". No warnings, no errors.

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

#107

Earlier quoted context omitted.

The first two of those are explicit design decisions: "explicit is better than implicit" and "we're all consenting adults" respectively.

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.

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

#108

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.

No, it's Python 2 that thinks those are all text. Python 3 makes you explicitly say "convert this stream of bytes into a text encoded string", and from then on it's a str object.

Python 2 was happy to (try to) let you call text methods on a JPEG. Python 3 draws an appropriate distinction between the two.

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

#109
In my experience, the biggest issue that I face is "what do you mean by Python 3?" I count 4 minor versions which aren't fundamentally broken, and I encounter them all on a regular basis.

A lot of my code is performance critical, and, for example, I'm still salty about dictionary operations taking O(log(n)). But the proliferation of active minor versions makes it very difficult to write portable, performant code.

It's become a sticky wicket. I want to migrate to Python 3 (and, by and large, I have in most of my projects). But what version do I target? Will my dependencies make the same choice? Or does "migration" turn into a sisyphean task? It's becoming burdensome enough that I'm contemplating abandoning the language for something more stable.

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

#110
post #79

Earlier quoted context omitted.

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.

Python has warts, but IMHO it's weird to identify valid design choices, with pros and cons on each side, as "warts".

If I were listing Python warts, I'd point to things like single-element tuples (1,), the `datetime` support (timezone-naive datetimes are an ambiguous disaster), or the cpython Global Interpreter Lock.

Post reply on HN