Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sunsetting Python 2

python.org

Post reply on HN
Print view View original

231–240 of 733 posts

Re: Sunsetting Python 2

#231

Post by bigiain »

CogitoCogito wrote: post #43
CJefferson wrote: post #21

Earlier quoted context omitted.

The biggest problem is having a place to organise. The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar name. Finding volunteers who are willing to get sued to work on Python will be hard.

I think you're blowing it out of proportion. Call your project some other name. Say that your interpreter is compatible with Python 2 and that you provide continued support. It will probably be hard to find volunteers because most are moving/have moved to Python 3, but I don't think the threat of lawsuit will scare anyone away except those who want to infringe on PSF's trademarks and in that case...good?

I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers?

What's "in it" for the volunteer? How much "fun" does "Supporting an old language where the original developers have moved on to a newer and more interesting version of the language, but there's a bunch of complaining people who still want the old language to be supported but they aren't offering to pay for it" sound? I'd rather sit in the park reading a book or walk a dog or something.

I mean, there's still people taking on COBOL contracts, because businesses consider their COBOL code to be important enough to keep maintained. But they sure as hell aren't "volunteering". They're getting paid rates that even bay area twenty-something FAANG-ers would be impressed by.

If Blackrock or The Vanguard Group or equivalent decided they needed continued Python2 support because it was a critical dependency on their ETF platforms (and they'd been foolish enough to not heed the "Goddamn it, just fucking upgrade to Python3 already!" advice from the core team for about a decade), I'm sure they could whip out their chequebooks and agree to a rate that Guido himself would agree support Python2 for them. But I'd hope and expect Guido (or whoever in the core team would be suitable candidates to do this work) to hold out for genuinely life-changing numbers of zeros on those cheques.

And if nobody is offering to write those cheques? Well maybe that says something about the seriousness of their complaints?

Re: Sunsetting Python 2

#232

Post by cogman10 »

shawxe wrote: post #226
wwright wrote: post #183

Earlier quoted context omitted.

If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.

Unfortunately, I think this type of thing actually is the case for many organizations. Trying to explain the business case for paying off technical debt to a non-technical person can be very difficult when "right now everything works."

I've had to fight developers over this.

A lot of devs like to not worry about new things.

Re: Sunsetting Python 2

#233

Post by marcus_holmes »

braythwayt wrote: post #179
PeterisP wrote: post #152

Earlier quoted context omitted.

You're waiting for other people to do stuff, and for many of them 1-2 years is the timeframe when they are likely to start working on it. From that perspective 1-2 years is not "too short", it's the "we intentionally chose this as the optimal time". That doesn't really depend on when the deadline is; if you postpone the deadline, then they postpone the migration - as pretty much every library did back in 2014 when th…

This x 1000. “The free libraries we chose to depend upon haven’t migrated.” Do you have programmers? “Of course.” Put them to work. “We have other priorities.” Well then. Your choice, your outcome.

This attitude is ridiculous.

I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline?

Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if you agree to ship v3 compliance by next month" is not reducing that pressure, it's adding to it.

More programmers != better results or faster delivery. Your solution is just going to create more problems.

Re: Sunsetting Python 2

#234

Post by bigiain »

PeterisP wrote: post #107
em500 wrote: post #29

Earlier quoted context omitted.

> RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me. Nobody expects new features in python 2.7, so this is basically all the support that people are looking for. RHEL7 will have security maintenance till Jun 2024.

As we see from the python3 switch motivation, the key support people need is support for their favorite libraries. In that regard, maintenance for python 2.7 would involve backporting security fixes also for popular 2.7 third-party opensource libraries and frameworks even if those libraries themselves have already switched to python 3 only.

I wonder how many 3rd party Python2 libraries RHEL ships with?

I wonder if Redhat have left themselves enough weasel words in their contracts to say "Oh Python2? No security updates to the interpreter! Oh, you wanted explioted-library-de-jour updated? Well that's not covered in your support contract here. Left me put you through to our professional service division. Please have your contract ID and credit card number ready when they answer - transferring you now!"

I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...

Re: Sunsetting Python 2

#235

Post by normalhuman »

jedberg wrote: post #62

In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet. In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now. For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backi…

> For my personal use case at least, this timeline worked out well for me.

Hint for Hacker News commenters: 99% of the time, if your phrase includes the term "use case", you can safely just delete it and lose no meaning. It's just a way to say "for me" or "for them" that sounds more technical but really isn't.

In this case, you could say "This timeline worked out well for me".

Re: Sunsetting Python 2

#236

Post by JeremyBanks »

voldacar wrote: post #228
voldacar wrote: post #104

I long for the day when typing "python" into a shell will bring up a python 3 prompt

And I would add - symlinking or shell aliasing does not count! I want a linux system without a single python2 binary anywhere on the disk! How many more decades must we wait??

Hopefully never.

If I have a modern C compiler, I can still run most C code from 30 years ago.

When I have a Rust 2030 compiler, I'll still be able to run Rust 2015.

But with only a Python 3 interpreter, I'm strictly unable to run the vast majority of Python code out there.

Re: Sunsetting Python 2

#237

Post by moomin »

marcosdumay wrote: post #208
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.

Try Hoogle.

Hoogle has its own problems...

Re: Sunsetting Python 2

#238

Post by madsbuch »

lonelappde wrote: post #185
pelario wrote: post #174

Earlier quoted context omitted.

I cannot agree enough. As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.

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

Re: Sunsetting Python 2

#239

Post by moomin »

lonelappde wrote: post #185
pelario wrote: post #174

Earlier quoted context omitted.

I cannot agree enough. As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.

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.

It really shouldn't be beyond the wits of the hackage developers to include a normative URL in old docs...

Re: Sunsetting Python 2

#240

Post by ken »

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...)

Dependencies? I helped upgrade a couple third-party modules, too. That's part of the job. If you choose to use a dependency, you're vouching for it. That means if the current version of the language no longer supports your favorite library, you need to fix the library, or find a new one. 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. Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips.

If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.

Apple took only 3 years to go from first announcing a new CPU architecture to releasing an x86-only OS. 2 years later, Rosetta stopped working, so there was no way to run old apps on current hardware at all. That's got to be one of the advantages of proprietary systems. It's amazing what you can accomplish when you have no choice. People complained a little but they got it done.

Post reply on HN