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

411–420 of 733 posts

Re: Sunsetting Python 2

#411

Post by LeanderK »

skywhopper wrote: post #401
ken wrote: 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…

As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users. Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that…

I am not sure what you want to say with your comment? That you move to another language as soon as there are breaking changes because you are invested as a user and therefore dissapointed? While this is a valid reason, it's just the way languages work. Some prioritize getting the language right and other backwards-compatibility. If your argument is categorical (languages that make breaking changes are bad) then indeed, python is not the language for your use-case (which is fine btw!). Java never made breaking changes, but it forced a massive limitation in the design-space for some language features (generics for example) for which it still pays a heavy price years later.

Also I think you're too harsh on the analogy, most of the time there's a way to write python2 and 3 compatible code, so which means the transition can go smoothly.

Re: Sunsetting Python 2

#412

Post by meowface »

normalhuman wrote: post #399
meowface wrote: post #377

Earlier quoted context omitted.

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…

> 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. It's not business jargon or a buzzword term, even if perhaps it started off that way many decades ago. Notice that you are already in contradiction with the first criticism that I received in this thread, where a subtle difference in meaning was proposed. > it means "in t…

I see your point, but I think it's only redundant if the context of the use case(s) has already been established, in which case you can just refer to the thing itself (directly, or with demonstrative words). If anything, I think the much more redundant and cringey part is the "personal" in "my personal use case". "My use case" sounds fine to me.

"My use case" just generalizes "my {project, job, task, case}(s)". It's not ambiguous, because the intention is to be general. "For me" is a bit more general than that, though, and sometimes you want to be a little more specific.

The specificity hierarchy / subtle difference in meaning goes from "for me" (my attributes) -> "my use case" (my attributes + the case's attributes) -> "my [job/project/whatever]" -> "my [exact thing I'm specifically doing]". I think all can be valid, depending on the context. I maybe should've said "'case' or 'situation' for a particular project or task or goal done by a particular person (or group or organization)" instead (I was implying the latter part), but there's no contradiction here. By contrast, "moving forward" is typically implied and unnecessary no matter the context and can usually be cut as dead weight.

Re: Sunsetting Python 2

#413

Post by foolfoolz »

skywhopper wrote: post #401
ken wrote: 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…

As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users. Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that…

the first part of this captures how my company has handled python 2/3. there’s probably 1-2 hundred thousand lines of python 2 that works well and is largely in maintenance mode. if we were going to change it, it would be a piecemeal step by step replacement to a different language, not upgrade to python 3. going from 2 to 3 in sufficiently large code bases is already a language rewrite. the company has moved on from python

Re: Sunsetting Python 2

#415

Post by partialrecall »

dagw wrote: post #158
jl6 wrote: post #121

Earlier quoted context omitted.

Did we read the same document? It seems fine and a perfectly normal explanation of what’s going on and why, like any software with a defined lifecycle would have.

I guess it depends what lens you are reading it through. If you're used to reading documents from open source projects it seems perfectly normal. If you're used reading documents from Oracle and SAP explaining changes to their long term support contract, then this will sound completely alien.

I for one am glad that my favorite FOSS projects do not talk like sterile Oracle PR drones, nor act like them.

Re: Sunsetting Python 2

#416

Post by zerkten »

lvh wrote: post #268
ken wrote: 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…

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…

> 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.

IIRC the messaging from Guido and Python core dev circa PyCon 2008 and 2009 was that it was good enough for people to start thinking about how they might migrate. This resulted in experiments with different approaches to migrations, maintenance of versions for Python 2 and 3, etc, but at that time there wasn't a clear end date and no rush to migrate. It seems like a lot of people misinterpreted what was actually said. Similar misinterpretations seem to happen within the wider internet community around the GIL and perf considerations. That cliff is finally here ten years later after a lot of experience with migrations.

Re: Sunsetting Python 2

#417

Post by arve0 »

brians wrote: post #287
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,…

I found some Unicode bugs in porting—and I get continued free security updates. Seems fair to me, and certainly not “no benefit”. I can keep on 2.7 as long as I like; nobody’s forcing me to port. Compare the situation with Java!

> Compare the situation with Java!

Isn’t that comparable to java? Oracle gives you paid security updates on version 8. You can keep using the previous version without security updates or migrate to OpenJDK 8, which have their own security group. More options, seems better to me.

Re: Sunsetting Python 2

#418

Post by Wheaties466 »

python 2 will continue to run on production systems for at least another decade, thanks to centos6 and making it basically impossible to upgrade to python3 as the main python binary on the system without completely breaking everything.

Re: Sunsetting Python 2

#419

Post by vegwarecompody »

skywhopper wrote: post #401
ken wrote: 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…

As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users. Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that…

>Instead, I spent my time moving to languages that had more respect for their invested users.

I’m not sure what more they could have done. Python 2 was released almost two decades ago, with an original planned sunsetting that got pushed back to 2020. That’s plenty of time and respect for their users.

>All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.

You’re free to stick with python 2 for as long as you’d like. You’re free to fork the project and continue develop it. To say there is no benefit to new and evolving languages is odd and short-sighted.

Re: Sunsetting Python 2

#420

Post by mixmastamyk »

slightwinder wrote: post #170
capitol_ wrote: post #163

Earlier quoted context omitted.

If 12 years is too short, how long timescale do you need? Python 2's EOL was first announced in 2008.

For the first 8-10 Years, migration was not possible for most people for several reasons, shrinking the timescale to 2-3 years for the majority.

Though you could have done most of the work ahead of time.
Post reply on HN