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

691–700 of 733 posts

Re: Sunsetting Python 2

#691

Post by jawilson2 »

djsumdog wrote: post #404
ofibrvev wrote: post #267

Earlier quoted context omitted.

> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg,…

You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot. If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. It's not just about Py2/3.…

My overriding motto as an engineer is "If it ain't broke, don't fix it." My python 2.7 component has run flawlessly for years now, with virtually no need to update. I just haven't had to worry about it. We decided to update to py3 a few weeks ago, and this component is now having sporadic hiccups. Like, it runs fine 95% of the day, then all of a sudden a timer callback in a Tornado ioloop just stops running for 30 seconds after working fine for 10 hours or something. This disables the entire trading system. It's hard to explain to anyone, myself included, what I gained by updating a perfectly working system to something that now shuts production a few times a day. Now my time is diverted from doing actually useful tasks to fixing code that wasn't broken to begin with.

Re: Sunsetting Python 2

#692

Post by alexhutcheson »

herbstein wrote: post #690
alexhutcheson wrote: post #671

Earlier quoted context omitted.

[not speaking on behalf of any employer, opinions my own] I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer l…

> The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Compiler errors sure would be handy here :^)

Those are probably the biggest missing piece. Compilers and static analysis tools make it possible for relatively small teams to migrate between compiler versions for C++, Java, etc. It's often still a huge amount of work, but it allows a lot of the work to be automated, and doesn't require an engineer to manually inspect every module.

Re: Sunsetting Python 2

#693

Post by carapace »

partialrecall wrote: post #676
carapace wrote: post #609

Earlier quoted context omitted.

> 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 Py…

> But it does indicate that they want Python 2 dead. Being less uncharitable, it indicates they want to avoid brand dilution (which is wholly reasonable.)

Okay, but then what do they get by avoiding brand dilution?

Look, I'm not really interested in proving that so-and-so is arrogant or not.

It's pretty clear to me that some people have some animosity to continued use of Python 2, and I find some of the language and attitudes smack of arrogance. I'm arrogant, and it takes one to know one, eh?

But I don't have a magic arrogance-o-meter so really what are we arguing about? Our feels?

Re: Sunsetting Python 2

#694

Post by overgard »

comex wrote: post #629
WorldMaker wrote: post #546

Earlier quoted context omitted.

The ubiquity of emoji alone mean that Unicode is everyone's problem in 2010+, and ignoring it won't make it go away. It's Python 2.x where dealing with Unicode (which is everywhere) is far too complex, and more trouble than it is worth. The "complexity" of Python 3 string handling is worth it, and no worse (even < 3.6) than any other modern programming language, and possibly easier than some by making clear runtime e…

Python 3's Unicode handling is uniquely bad. I haven't heard of any other language where you can obtain magic strings that crash the program if you try to print them: % python3.7 -c "import sys; print(sys.argv[1])" "$(echo -e '\xff')" Traceback (most recent call last): File " ", line 1, in UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 0: surrogates not allowed

That seems more like a difference of opinion on how to handle a bad string than an example of python 3 being bad. I'd argue failing silently is worse, as in programs outside of your toy example you might end up storing badly encoded data etc. Broken data is way worse to deal with than a crashing app

Re: Sunsetting Python 2

#695

Post by carapace »

gnulinux wrote: post #686
carapace wrote: post #524

Earlier quoted context omitted.

I just realized I didn't answer your actual question, sorry. > what is it that you like about Python 2? I came from C and Pascal so from that POV Python is a rich and delicate syntactic and semantic gravy over the same basic functionality plus shell (Python was originally the shell language of the Amoeba distributed OS†). Things that might not seem that big a deal these days were a revelation to me when I started wit…

But all of these are in python 3 too?

Yes, but...

Because 3 is incompatible with 2 I evaluate the cost/benefit of using it compared against all other languages, not just 2.

From that POV, I find that e.g. Julia, Haskell, or Prolog are much more compelling than Python 3. Python 3 doesn't add anything radically better than 2.

(Most of the new language "features" to me seem like they should be libraries instead: fstrings, enums, dataclasses; I can't understand why people think asyncio is cool but ignore Twisted (which is a huge treasure chest of amazing capabilities!))

Since I see 3 as only marginally better than 2, the main difference between them is that 2 is stable and mature while 3 is in flux, and that consideration mashes the cost/benefit ratio waaaay over in favor of 2, IMO.

Re: Sunsetting Python 2

#696

Post by paulmd »

mindcrime wrote: post #517
gridlockd wrote: post #514

Earlier quoted context omitted.

"Hey boss, we're gonna use this hip new language that will break everything for no good reason a few years down the line." Congratulations. You're fired.

"Hey Joe, why did our customer database get leaked and published on a dark-net site?" "Hey boss, we're using an outdated programming language for which security updates are no longer provided, because we were told there's no budget for fixing technical debt." "Congratulations, you're fired." Same outcome either way... might as well make some effort to do the right thing along the way...

Nah, you're not fired. That's why you CYA and get it in writing. It's the manager who decided that they didn't want to do a rewrite, it's not your problem they didn't listen to your advice.

Like it or not, there are a lot of teams that choose to incur technical debt to avoid what is seen as needless work on something that is working fine at the moment.

Re: Sunsetting Python 2

#697

Post by carapace »

depressedpanda wrote: post #628
carapace wrote: post #524

Earlier quoted context omitted.

I just realized I didn't answer your actual question, sorry. > what is it that you like about Python 2? I came from C and Pascal so from that POV Python is a rich and delicate syntactic and semantic gravy over the same basic functionality plus shell (Python was originally the shell language of the Amoeba distributed OS†). Things that might not seem that big a deal these days were a revelation to me when I started wit…

While I agree with most of your points, nothing you said really highlights why python2 is better than python3. (Also, you're definitely not fucked with more than 100k LOC of Python, if the devs know what they're doing. Unit/regression/integration tests, type hinting, and a modular design goes a very long way)

> nothing you said really highlights why python2 is better than python3.

I never said that. In fact, I admit that in some ways 3 is better than 2. However, that 2 is static (unchanging) while 3 is being actively changed means that, as time goes on, the cost of using 2 will decrease while the cost of using 3 will increase.

> Also, you're definitely not fucked with more than 100k LOC of Python, if the devs know what they're doing. Unit/regression/integration tests, type hinting, and a modular design goes a very long way

I was engaging in a bit of rhetorical flourish there. I know it can be done, but it's not Python's "sweet spot". For large projects, Java or Haskell or even Ada are preferable IMHO. And I say this as a Python partisan.

Cheers!

Re: Sunsetting Python 2

#698

Post by carapace »

afiori wrote: post #639
carapace wrote: post #612

Earlier quoted context omitted.

I get what you're saying and I think you're pretty much describing what it will be like. But honestly, I'm kind of looking forward to it. To me it's like maintaining a favorite model train set or something. A labor of love. (Going forward I'm more likely to use Julia, Haskell or Prolog than Python 3 for new code.)

I am interested in your opinion on an idea. What do you think it would have happened if python 3 included a python 2 interpreter (as a command line flag or even a library) so that everyone could switch to python 3. I understand they where almost incompatible as runtimes so it would have doubled size but it would make easier to propagate the diffusion of python 3. Do you think a project such as Bladders would have bee…

FWIW, I think that if 3 had the ability to run 2 code (on a per-module basis, say) the whole mess would have been avoided.

Honestly, I'm not so much a Python 3 hater, as a lover of stability. To me the idea of Python 2 being stable for the foreseeable future is exciting because it means I can concentrate on improving the tooling (e.g. tools like PySonar and Snakefood and such. I would add MyPy but of course they will be chasing Python 3 now.)

> Do you think a project such as Bladders would have been still possible had this happened?

Maybe... You can run C code from decades ago. That's pretty awesome. I guess it would depend (in this hypothetical) on whether the 3 interpreter was ever going to drop support for 2 code.

Re: Sunsetting Python 2

#699

Post by carapace »

minitech wrote: post #610
carapace wrote: post #492

Earlier quoted context omitted.

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

That's a good point. There are certainly some warts in 2 that are fixed in 3. Cheers!

Re: Sunsetting Python 2

#700

Post by al2o3cr »

CJefferson wrote: post #471
ilikehurdles wrote: post #362

Earlier quoted context omitted.

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.

Python 2 code, broadly speaking, still runs in Python 3. It's the not-broad parts that are the problem...
Post reply on HN