Hacker News Reader

Comment by scardine | Hacker News Reader

What I find most curious about Django/Python is that about 30% of the new installs are for legacy Python/Django (2.7/1.11):

  $ pypinfo --start-date 2019-01-01 --end-date 2019-03-31 -- 
  percent --markdown django pyversion
  Served from cache: False
  Data processed: 160.22 GiB
  Data billed: 160.22 GiB
  Estimated cost: $0.79

  | python_version | percent | download_count |
  | -------------- | ------: | -------------: |
  | 3.6            |  39.61% |      3,277,927 |
  | 2.7            |  29.59% |      2,448,652 |
  | 3.7            |  17.53% |      1,450,949 |
  | 3.5            |  10.37% |        858,325 |
  | 3.4            |   2.76% |        228,150 |
  | 3.8            |   0.07% |          5,428 |
  | 2.6            |   0.04% |          3,686 |
  | 3.3            |   0.03% |          2,103 |
  | 3.2            |   0.00% |            220 |
  | None           |   0.00% |             56 |
  | Total          |         |      8,275,496 |

I would expect everybody moving over 3.x by now - we are so close to 2.7 EoL in December...

View on HN

I wouldn't call it "new installs" - most of the PyPI downloads in any category are going to be from deployment scripts.

It shows that 30% of projects being re-deployed are still on Python 2.7.

I think you nailed it - I wonder how many of those installs are from CI tools.

Trying to move, but it's tough. Old codebase, lots of deps, and no real benefit to upgrading to 3.6, nothing our end users will care about or notice (or pay for).

Upgrading to Python 3 is a chore. We have to do it, but it's not fun and it's barely useful.

Well said.

I would argue py3 has negative utility for that reason. Plus, the mess of 3.5 vs 3.6 vs 3.7.

What happened between those?

Nothing obviously a "mess." Your guess is as good as mine.

At worst async became a keyword in 3.5. I have to say I am enjoying f-strings from 3.6.

don't your users in 2020 care you are using an unsupported language? security wise

Of course not. That's the point.

the users care that your site is secure, especially if you're using their confidential info.

can you achieve security with a dead language? I don't think so.

Users care very little about security, actually.

Many many organizations are acting as if completely unaware of the EOL.

I assume they will simply run on the last 2.7 release until projects are shut down.

If I had any Python 2.7 stuff, I would simply move it to Pypy which has no such obsolescence date.

It's not just Python 2 itself that's going away, it's many of the popular packages for it, as well. Some are specifically waiting for 2.7 EOL to pull the plug on their side, so it's going to get much worse for anybody stuck on it.

Aren't there a ton of legacy 2.7 programs installed onto OS's that then probably download 2.7 to work?

e.g. some script has '$python my_program --arg foo' hardcoded instead of '$python3 my_prgram --arg foo'

2.2 is the first LTS since 1.11. I expect a lot of people will upgrade now that it's out.

Edit: Oh, but that doesn't account for the older Python version. Yeah, that is interesting.

Bitter clinger to 2.7 here.

I'm sure the IPv6 group expected the world to have migrated more quickly, too.

Not to bring back an old debate, but I simply want to point out the obvious: many data scientists disliked Python 3.x. I work with Python people who dislike Python 3.x, and we are still using mostly 2.7, because everyone feels comfortable with it. The upgrade seems to be a large imposition, with zero gain.

Well, it is understandable. Winds are changing though...

The lack of (enough) incentive for upgrading used to be a good excuse but with 3.8 we are getting a few performance updates that are hard to ignore. Also, many projects in data sciences are dropping support for legacy Python so sooner or later data processing pipelines will have to catch up.

Yes, upgrading is unpleasant, but it is becoming a matter of hygiene.

Given the amount of mojibake I've had to clean out of databases I'd have thought that data scientists would be the first to latch on to sane Unicode handling instead of the willy-nilly string handling inherent with py2.

Reply on news.ycombinator.com