Sunsetting Python 2 • Hacker News Board

Re: Sunsetting Python 2

#471

Post by CJefferson » Mon, Sep 09, 2019, 5:16 PM UTC

ilikehurdles wrote: post #362

CJefferson wrote: post #269

Earlier quoted context omitted.

To be honest, never. I work on a C program that's about 30 years old. We've slowly moved, at our own pace, to C99, then added some C++ here and there. I don't ever want to have a forceful change, where I have to go and edit code which has worked correctly for over 15 years, just to make a compiler happy.

GCC deprecates and removes support for target architectures and various other flags with each major release. If you care about receiving security updates for your application, you have to upgrade the compiler, and to upgrade the compiler you may have to make changes to your application and/or physical hardware. Very few of the architectures that were available 30 years ago are still supported by any maintained compil…

We are moving CPUs, we aren't still using amigas and 386s :) but old C code, broadly speaking, still compiles in gcc 8.

Re: Sunsetting Python 2

#472

Post by __jal » Mon, Sep 09, 2019, 5:16 PM UTC

madsbuch wrote: post #238

lonelappde wrote: post #185

Earlier quoted context omitted.

This issue is part of why Haskell is so hard to learn. Haskell's package database Hackage keeps all old deprecated incompatible versions of packages, with documentation pages all well indexed by Google, with higher page rank because they are longer lived than the current package version, with no indication that they are deprecated and incompatible with current Haskell deployments.

This is also the problem haskell stack solves

"Haskell. The cause of, and solution to, all of life's problems."

Re: Sunsetting Python 2

#473

Post by ilikehurdles » Mon, Sep 09, 2019, 5:16 PM UTC

privateSFacct wrote: post #453

madeofpalk wrote: post #438

Earlier quoted context omitted.

> I just want to keep using Python 2. Honestly curious as to why you would prefer to stay behind?

Anyone with a large python 2 codebase is going to want to stay behind if they could. People still run old FORTRAN from 20 years ago in production. I'm sure some old COBOL code is out there. The reality of not wanting to re-write working code is somewhat real.

This is such a good analogy, and really highlights the point that python 2 stalwarts look at organizations hiring for FORTRAN and COBOL today, and say to themselves, "Yes, this is the kind of organization I want to build." An organization that will either (most likely) be completely irrelevant in 10 years time or have to pay a massive premium salary for any engineer that can maintain their systems.

Re: Sunsetting Python 2

#474

Post by logifail » Mon, Sep 09, 2019, 5:16 PM UTC

meowface wrote: post #377

normalhuman wrote: post #361

Earlier quoted context omitted.

Corparate-speak that makes its way into common language is frequently justified post-hoc by subtle differences in meaning like the ones you allude to. The problem is that these differences are personal and subjective. Ask someone else, they might have a different answer. I have had the same discussion multiple times over the equally meaningless and inelegant "going forward". "Use case" comes from 90s software enginee…

This seems extremely pedantic. "Use case" as it's used today basically just means "case" or "situation" for a particular project or task or goal (edit: and for a particular individual/group/entity/organization). It's not business jargon or a buzzword term, even if perhaps it started off that way many decades ago. I can think of countless annoying corporate buzzwords I see all the time on HN or at my job which are tot…

> "Use case" is two simple English words which anyone, including non-tech people, uses and clearly understands

Source?

Where I am "use case" is definitely [still] tech jargon. I know very very few non-tech people who've ever heard it used, much less could give a definition for it.

Re: Sunsetting Python 2

#475

Post by CJefferson » Mon, Sep 09, 2019, 5:17 PM UTC

ZWoz wrote: post #425

CJefferson wrote: post #211

Earlier quoted context omitted.

Sorry, I shouldn't assume people know the same things I know. I know this has come up at least three times I've seen, but I'm having trouble finding them all. Here's one: https://github.com/naftaliharris/tauthon/issues/47 In this case there was plans to call something py28, to which Guido replied "OK, bring in the lawyers".

CJefferson probably refers that GvR comment (Though I don't see that strong language here): """ Since I was asked: The project's name (and its binary name) need to change. They are misleading. The rest looks acceptable according to Python's license. This is not an endorsement (far from it). """

Expand all comments. One is exactly what I quote.

Re: Sunsetting Python 2

#476

Post by partialrecall » Mon, Sep 09, 2019, 5:18 PM UTC

carapace wrote: post #447

bigiain wrote: post #264

Earlier quoted context omitted.

> Totally agree, there's some degree of arrogance Me too. Anyone who's running 15+ year old free software which came with 6 or possibly 12 years of notice to upgrade to the new version (depending on how you count it) and is complaining that it's no longer going to be supported for free by someone else, is being quite amazingly arrogant... Maybe it's unintended, users of free software are not always good at being grac…

Yes, those people are arrogant and/or entitled, but you know darn well that's not the arrogance GP was talking about. It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet. As choppaface said, > Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback. If Python 3 could run P…

> It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.

That's a strange way to characterize "decide to no longer volunteer their own time." And by strange, I mean rude. If you want somebody to spend their time maintaining python2, why don't you cough up the cash?

Re: Sunsetting Python 2

#477

Post by mindcrime » Mon, Sep 09, 2019, 5:21 PM UTC

kortilla wrote: post #317

sdoering wrote: post #250

Earlier quoted context omitted.

> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful d…

Well it’s a shitty analogy because a swap to torx is basically a single API change. The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it. “Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.

Most non-tech businesses have no budget for that kind of tech debt work.

That's fine. I'm sure there are some that also don't have a budget for fire insurance, or a security system, or whatever. For anybody who wants to gamble with no fire insurance, or not fixing tech debt, that's a conscious choice they get to make. Now they have to be responsible for the outcome(s) of their choices.

Re: Sunsetting Python 2

#478

Post by ben509 » Mon, Sep 09, 2019, 5:22 PM UTC

radlad wrote: post #312

lvh wrote: post #268

Earlier quoted context omitted.

One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came…

> Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1? > core dev did not listen to any of the problems people pointed out for _years_ What problems were those?

A major, breaking issue[1] was how Python 3 handled missing LC_* variables. By default, a Python script would simply crash with any non-ASCII input or output. It was fixed[2] in 3.5[3].

[1]: https://bugs.python.org/issue19977

[2]: https://www.python.org/dev/peps/pep-0540/

[3]: https://docs.python.org/release/3.5.0/whatsnew/3.5.html

Re: Sunsetting Python 2

#479

Post by ilikehurdles » Mon, Sep 09, 2019, 5:22 PM UTC

mk89 wrote: post #88

gigatexal wrote: post #60

The transition to python 3 from 2 was rough I’ll give you that. But companies and maintainers have had years and years to either fork and port or altogether rewrite their code for python 3 — the only python that matters. I liked the stance the post took: it was very matter-of-fact in its tone regarding python 2 support — consultants are there for that and they will charge a mint to give you time you should have taken…

From my experience, large codebase refactorings are almost never a priority until the deadline is just right there. 10 years for many companies mean the last 6 months, when everyone else has already done a lot of work on the same problems as you will encounter, lots of issues have been already solved, and you can probably find people with the python 3 skill. And last but not least, you will find approvals from manage…

That's true. I worked at an enterprisey shop that delayed upgrading from Java 6 before its EOL. By the time they started, the EOL date had passed a few months prior and the upgrade itself was a 1.5 year effort. Some orgs can be pushed, others have to be shoved.

Re: Sunsetting Python 2

#480

Post by pfranz » Mon, Sep 09, 2019, 5:24 PM UTC

dna_polymerase wrote: post #353

dahart wrote: post #331

Earlier quoted context omitted.

Python 3.1 came out 10 years ago. 3.2 was released in 2011. What does that mean about the complaints since, let’s just say 2015 to be fair?

I heard several people saying that 3.6 was the first Py3 worth transitioning to. Largely for async (I think async/await came to live then). There is this take on performance: https://hackernoon.com/which-is-the-fastest-version-of-pytho...

I do think "worth transitioning" is the final group of people who have the most reason to hold off. If new features are what made it worth transitioning, then it probably was 3.6 with async/await. If you relied a lot of unicode and already had a mature codebase, you'd wait too. If it was a new project you'd probably start with 3 much earlier because of unicode.