Live data from Hacker News

Sunsetting Python 2

python.org

551–560 of 733 posts

Re: Sunsetting Python 2

#551

Earlier quoted context omitted.

No one is saying you can no longer use Python 2. The community is just saying that if you do, you're more or less on your own. Python 2 won't magically stop working on Jan 1 2020.

In the world of commercial computing, nobody can work on a language that is not supported. Essentially what they are saying is that companies need to scramble to port their code to Python 3 or risk running their systems in an unsupported language. This will in practice be just another hurdle that users need to go through to continue using Python.

Those companies can pay someone else to provide support for Python 2.

Re: Sunsetting Python 2

#552

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

I think this is where paid support comes into picture. Volenteers can keep improving Python, business that cant/wont upgrade can pay someone to "handle it", and consultants can make money. Everyone is happy.

The FAQ does point to vendors that plan to offer long time support/conversion paid support plans.

Re: Sunsetting Python 2

#553
post #430

Earlier quoted context omitted.

The GIL constraint has not.

If the GIL is so important to you that you're willing to suffer the pain of running on another VM with a much-reduced ecosystem, while at the same time having requirements so complex that PyPy cannot meet them, maybe Python is just not the right tool for the project.

Moved the goalposts.

Re: Sunsetting Python 2

#554

Earlier quoted context omitted.

You've never encountered badmouthing from a pro builder about other tool brands? How many did you talk to? Builders make the Ford v Chevy debates look minimal in comparison.

I think he means more 'craftsman' vs. 'builder' in mentioning professionals. I don't think there's a time I can remember when Norm Abram (probably now one of the greatest or at least most prominent carpenters of a generation) ever mentioned the particular tool brands he was using. And looking back on earlier seasons of This Old House, he was hand-nailing thousands of nails a day (nowadays he and everyone else often u…

Having used quite a few different brands over years,I'd say that most of the more expensive ones are just good enough.All the nitty gritty details why Makita does a better job than HILTI or that Milwaukee will last forever are mainly personal experiences.

Re: Sunsetting Python 2

#555
post #240

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...) Dependenc…

How well would that work on MacOS?

Re: Sunsetting Python 2

#556

Earlier quoted context omitted.

> But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...

Driving an EV without charging stations is (nearly) useless. You can still run Python 2-3 code with a Python 2 interpreter with no significant consequence.

EV drivers don't need charging stations at all if they have an open plug at home or at work. The metaphor still sort of works that Python developers had plenty of time where maybe they didn't have enough charging stations on the wide open highway roads of Production to use Python 3 there, but certainly could have been happy to use an EV to commute from home (hobby projects) to the work parking lot (side projects, automation projects, new projects) and back while they waited for those "charging stations" to be built.

Re: Sunsetting Python 2

#557

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.

Actually most of them do money, however in these type of companies tech people aren't listed to as much,as maybe sales or finance are. It just depends on who's running the circus on the day: if it's a guy with short term goals only- you'll never get a budget,but the ones with longer visios would most likely listen.

Re: Sunsetting Python 2

#558

Earlier quoted context omitted.

>Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively develope…

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.

I might be misunderstanding your comment, but I have encountered source code that is not forward compatible in java. Some examples below...

Incompatibilities between JDK 7 and JDK 6: https://www.oracle.com/technetwork/java/javase/compatibility...

Incompatibilities between JDK 8 and JDK 7: https://www.oracle.com/technetwork/java/javase/8-compatibili...

An exerpt from the Compatibility Guide for JDK 8 [1]:

>In general, the source compatibility policy is to avoid introducing source code incompatibilities. However, implementation of some Java SE 8 features required changes that could cause code that compiled with Java SE 7 to fail to compile with Java SE 8. See Incompatibilities between Java SE 8 and Java SE 7 and Incompatibilities between JDK 8 and JDK 7 for information.

There are also a plethora of deprecated and removed APIs throughout Java's history.

[1]:https://www.oracle.com/technetwork/java/javase/8-compatibili...

Re: Sunsetting Python 2

#559

Earlier quoted context omitted.

Out of curiosity, what is it that you like about Python 2? Not attacking you, just curious. I've never used Python professionally (mostly Ruby and Clojure), so I don't have a horse in this race.

Cheers! Answering you for all three (at the moment) comments asking: Okay, here goes. In brief, Python 3 adds work without adding significant (to me) value. As others have pointed out, you don't get anything from converting an existing project from 2 to 3 other than compatibility with 3. If the Python 3 proponents were to succeed in killing 2 then that becomes compelling, however, since I intend to maintain 2, I don'…

One very high cost to staying on 2 will be that the pool of 3rd party modules you can draw from will continue to shrink as projects drop support for it. Sure, you can stay on Requests v.whatever, but eventually the SSL certs that it includes will expire, and then you'll have to maintain your own patched Requests with the new certs you want to use. Or eventually someone will find security problems with Django 1.11 LTS, and will be on you to fix them. Also, every Django plugin will have migrated to Python 3, so you won't get to use the new tools for it that everyone else is using.

And at some point, say 10 years from now, you'll reach your breaking point where you'll get tired of maintaining backports for every. little. package. that you want to you use. And when that day comes, then you'll face the even more daunting task of porting your stuff to the new current version of Python.

I'm saying this as one techie to another: don't do this to yourself. Not long term, anyway. If you want to support your own ecosystem for six months or a year as an exercise, sure, I'll be the last one to tell you not to work on a personal project you enjoy. But for Pete's sake, don't engage in this as a long-term project. This isn't how you want to look back on your deathbed and see that you spent a decade.

As a practical matter, I'll say that everyone I've spoken to seems to have the experience that Python 3 seems like a pain in the neck for a very short while as you go through the process of finding all the bugs in your codebase that Python 2 was letting you ignore. But once you've done that, you're not going to want to go back and un-fix them even if you decided to stick with Python 2, and if you've already gone through that work, why not enjoy the new language features and 3rd party packages now available to you?

Re: Sunsetting Python 2

#560

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.

Are people routinely still purposefully writing new code in 20 year old versions of FORTRAN, or just maintaining existing stuff?
Post reply on HN