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

601–610 of 733 posts

Re: Sunsetting Python 2

#601

Post by mynameisvlad »

mikepurvis wrote: post #296
shakna wrote: post #124

Earlier quoted context omitted.

Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.

It's interesting seeing who the holdouts are, though. Less than a year ago, the CEO of Sentry (the crash reporter) locked a Github thread with essentially "we'll get there when we get there, sometime in or after 2020." But then, as late as 2016 their stance was pretty much that they would never migrate, so I suppose it's not surprising that they aren't super prepared for it: https://github.com/getsentry/sentry/issues…

His responses leave an incredibly sour taste in my mouth. Not only is he obviously short sighted with his "Python 2 is not the past and Python 3 is not the future" but all his responses just sound like someone who got up on the wrong side of the bed. Every morning.

Re: Sunsetting Python 2

#602

Post by acdha »

musicale wrote: post #567

This would never have been such an unpleasant issue if Python 3 hadn't broken backward compatibility in very annoying ways; one of the more inexcusable examples was removing the print statement, a convenient piece of syntax that dates to antiquity, and which could have peacefully coexisted with the print() function in Python 3. Now that Python no longer has a BDFL, maybe we'll get the print statement back? ;-p

That’s something which takes literally seconds to safely fix across an entire project using modernize/futurize, along with the better exception handling syntax, etc. It’s just not worth clinging to the past at this point.

Re: Sunsetting Python 2

#603

Post by a1369209993 »

kstrauser wrote: post #446
carapace wrote: post #421

Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curat…

But... why? Python 3 has been "good enough" since 3.4. By 3.6, it was markedly better than 2. With the upcoming 3.8, it seems to be better in every way (including performance!). I loved Python 2 for a long time. It was a beautiful language. But after seriously using 3, I would never go back. As in, I would turn down job offers involving Python 2 in any other context than "we're hiring you to help us upgrade".

Have they even managed to get

  print(b"byte = FF (\xFF)")
working correctly yet?

Never mind `print(len("ẅ"))`[0] and the like.

0: https://news.ycombinator.com/item?id=20246676

Re: Sunsetting Python 2

#604

Post by chrisoverzero »

CJefferson wrote: post #211
XCabbage wrote: post #52

Earlier quoted context omitted.

You've asserted this twice on this post, both times without any evidence. I Googled, couldn't find the threat you're basing the claim on, but DID find that the PSF Trademark Usage Policy ( https://www.python.org/psf/trademarks/ ) explicitly allows most sorts of freely distributed Python-related products to use the name without permission: > Use of the word "Python" in the names of freely distributed products like Iro…

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".

That is an absurd mischaracterization of the conversation. Guido’s response to the “py28” name was only, “Doesn’t work for me, sorry.” The “lawyers” response was specifically a response to an aggressive, insulting post from another poster. That other poster said that Guido should be disregarded, suggested names that would clearly get lawyers involved if chosen, accused Guido of sabotaging Python 2, and characterized Guido’s naming objections as silly. To Guido’s (virtual) face, no less! He was described by the original poster in that thread as hostile, antagonizing, and rude. Any reasonable reading of that single sentence post from Guido is of his giving up – throwing up his hands and saying the equivalent of “Well, whatever, then.”

---

gvanrossum: Isn't the whole point that we're trying to solve this without lawyers?

[redacted]: The whole point is that you've been sabotaging Python 2 for years and when someone does what needed to be done from the start, you come up with silly objections.

gvanrossum: OK, bring in the lawyers.

---

Just don’t appropriate a name what’s not yours, and you can maintain all the Python 2.x you want. Pathfinder[1] couldn’t call itself D&D 3.6 – Tauthon or anyone else can’t make things called Python.

[1]: https://en.wikipedia.org/wiki/Pathfinder_Roleplaying_Game

Re: Sunsetting Python 2

#605

Post by acdha »

coliveira wrote: post #485
gwbas1c wrote: post #407

Earlier quoted context omitted.

No Typically version N+1 of a language compiles version N, N-1, all the way back to version 1. Usually, when this isn't the case, the incompatible areas of a language were either marked experimental, or obscure use cases that very few people use. Today's Java compiler will compile source code written for Java 1. The issue with Python 2 and Python 3 is extremely unusual in a language.

Exactly. People who think that the Python situation is normal don't have any experience with programming languages. C compilers can compile code that was written 40 years ago. Java can do this all the way to version 1. Python requires you to make an effort to chose the version of language you want, otherwise the tooling system won't let you run that code. It is true that they later created tools to help with this pro…

If you think that’s true, you haven’t supported enough legacy C code. Yes, the core language hasn’t changed much - like Python - but the includes, libraries, operating system APIs, etc. have - and that’s before you learn how vague compatibility was for code written before sometime in the 90s. Similarly, I’ve seen large Java projects take years to upgrade while comparability issues are sorted out.

In all cases, the real problem is technical debt management: rather than attacking people who gave you something for free, ask whether it’s possible that the experience has more to do with procrastinating on upgrades until many large changes have to be made at once with inadequate test automation.

Re: Sunsetting Python 2

#606

Post by philwelch »

mindcrime wrote: post #477
kortilla wrote: post #317

Earlier quoted context omitted.

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.

There's not budgeting for fire insurance or security systems, and then there's deliberately building your workplace next door to an asylum for pyromaniacs and across the street from a gas station.

If you built software using Python 2 at any point in the past 5 years, you have no right to complain about the added technical debt of updating to Python 3. But not wanting to incur that technical debt in the first place would also have been a good reason not to use Python 2 in the first place; whether that means adopting Python 3 early or simply using a completely different language.

Re: Sunsetting Python 2

#607

Post by simcop2387 »

bigiain wrote: post #586
simcop2387 wrote: post #572

Earlier quoted context omitted.

That's also why I added COBOL, that and to test some ideas on how to handle compiled languages on it. The backend service supports multiple files but I haven't finished the web side of things to handle that (I have a strange requirement to make it work without javascript).

If you're after stupid suggestions, would it be "breaking your personal rules" to use only enough Javascript to allow just enough of a transpiled version of the in-browser Java runtime to let '90s vintage Java Applets run? Or maybe Flash? (And no, I'm 100% not offering to do any of the work required to make that come true... ;-) )

I'd be willing to try something like that, but both flash and java applets are horrendously complex. The javascript restriction is because it's mostly used by us perl developers on irc and there's a few disgruntled greybeards that will actually use it via lynx or links. Closest thing for flash is shumway, https://mozilla.github.io/shumway/ which might be possible to make work but it's still got a lot of compatibility issues from what i hear.

Re: Sunsetting Python 2

#608

Post by mantap »

raspie wrote: post #565
sametmax wrote: post #508

Earlier quoted context omitted.

By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones.…

I think it's less about the difficulty of manual changes and more about the cost to verify that all of the changes actually work. Dynamic typing on the language side, and a less than perfect test suite on the user side are not a good combination for large projects facing a project wide migration.

It's about risk. Python is a scripting language. That means that it's often auxiliary to a primary programming language. Your project might be in C++ but you use Python to package it or generate some assets, etc. Do you really care what language your auxiliary scripts are written in? No. Are you going to spend any amount of time converting them to Python 3 syntax? No. Your boss doesn't care, and you don't care. It would only end badly.

Re: Sunsetting Python 2

#609

Post by carapace »

partialrecall wrote: post #507
carapace wrote: post #503

Earlier quoted context omitted.

First, > why don't you cough up the cash? I am. Second, > "decide to no longer volunteer their own time." If that's all they were saying I would STFU. They are also telling everyone that, once they stop volunteering, Python 2 is dead. They insisted that the Tauthon project rename itself. It's one thing to say, "we won't support it", it's another thing to actively try to kill it, especially when they know people are s…

Making them use a name other than python is hardly any great hardship. Mozilla maintains their trademark too and nobody whines to hard about that. Just call it "boa" or something. Firefox->Icecat.

> Making them use a name other than python is hardly any great hardship.

It wasn't. (And Tauthon is arguably a really cool name.)

But it does indicate that they want Python 2 dead.

> Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them.

http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...

Like I said, if people were just fading out of Python 2 that wouldn't make me call them arrogant, it's when they insist that other people have to ditch Python 2 that I start to feel like there's some arrogance there.

Like I said in a another comment, the only thing you get from switching to Python 3 is Python 3 compatibility. If Python 2 remains viable (which it will) there's much less incentive to use 3.

Python 2 isn't broken or bad or anything, it's just not Python 3. We aren't being urged to switch because 2 is (so much) worse than 3 but because it's a viable competitor to it.

Re: Sunsetting Python 2

#610

Post by minitech »

carapace wrote: post #492
kstrauser wrote: post #446

Earlier quoted context omitted.

But... why? Python 3 has been "good enough" since 3.4. By 3.6, it was markedly better than 2. With the upcoming 3.8, it seems to be better in every way (including performance!). I loved Python 2 for a long time. It was a beautiful language. But after seriously using 3, I would never go back. As in, I would turn down job offers involving Python 2 in any other context than "we're hiring you to help us upgrade".

> By 3.6, it was markedly better than 2. Better how? Or better at what? It's likely that our opinions will be different but I've got an open mind and I'm genuinely curious about your experiences and opinion. (I hated PEP 572 at first but then some comment here on HN made me rethink and change my mind.)

For me, it’s better at avoiding mistakes. The major one is separating bytestrings from strings, of course. Comparison operators not assigning a default order to different types (1 < "2" is now an error) is great. Division is more explicit. Explicit relative imports save me grief. Similar changes about providing APIs that are harder to misuse throughout the standard library.
Post reply on HN