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

Python 2.7 Countdown

pythonclock.org

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Python 2.7 Countdown

#61

Post by toyg »

jeremiep wrote: post #20
toyg wrote: post #11

Earlier quoted context omitted.

Macos still ships an outdated openssl, bash, etc etc... Apple are the definition of “lag” for developer tools.

It has to do with licenses. They're shipping the last GPLv2 version of bash for one, the new versions are on GPLv3. I don't get why people bash things when they clearly don't understand the full context (pun intended ;)

They've always been slow, even when licensing was not an issue.

OpenSSL is not GPL3. They still shipped a very old version, then apparently switched to LibreSSL... and promptly shipped an old version of that.

They lag. Licensing is an issue for a subset of tools, but lagging is very much an issue for all of them.

Re: Python 2.7 Countdown

#62

Post by yeukhon »

faragon wrote: post #58
yeukhon wrote: post #35

Earlier quoted context omitted.

http://www.curiousefficiency.org/posts/2014/08/python-4000.h... It will be backward compatible (unless there is an absolute need to break), but just keep Python 4 out of your head. For now, they predict just 3.10+

"unless there is an absolute need to break" So when someone has to decide between language X and Y, with the risk of another Python 2.x to 3.x "drama", that argument would be an important point for picking one language or another. For long term decisions "predictions" are a risk, i.e. not committing in backwards compatibility. Commitment reduces the risk. I asked for commitment not because of "purity" but because of…

In some cases, if they have to break it, they have to break it. CPython developers are notorious for writing PEP and takes so many iterations, debate till end of the world, in order for the developers to accept and publish a PEP.

While I do not speak for any of them, what the blog post is trying to say is they have made a mistake with the 2 to 3 transition by introducing so many breaking changes. Instead, they have acknowledged this mistake, and will work very hard to not break anymore. But they also want to reserve a tiny room so they are not called "you lied to us!" Perhaps some fundamental change has to be made.

If there is one person who hates breakage, it will be Linus.

See http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

He made it clear that over the years, there has been very few exceptions allowed. On the contrary, he mentioned that kernel internal APIs are fine to break.

What we want to achieve in general, according to Linus, is avoid breaking user APIs (or userland in Linux). But rest assure, when some new language feature added, or changed, or broken in CPython, you can expect a PEP.

Lastly, you still have the option to send the devs (including Guido) an angry email on python-dev :-) The devs are users themselves, so I am sure they are sympathetic with the pains in the 2-to-3 transition.

Re: Python 2.7 Countdown

#63

Post by faragon »

yeukhon wrote: post #62
faragon wrote: post #58

Earlier quoted context omitted.

"unless there is an absolute need to break" So when someone has to decide between language X and Y, with the risk of another Python 2.x to 3.x "drama", that argument would be an important point for picking one language or another. For long term decisions "predictions" are a risk, i.e. not committing in backwards compatibility. Commitment reduces the risk. I asked for commitment not because of "purity" but because of…

In some cases, if they have to break it, they have to break it. CPython developers are notorious for writing PEP and takes so many iterations, debate till end of the world, in order for the developers to accept and publish a PEP. While I do not speak for any of them, what the blog post is trying to say is they have made a mistake with the 2 to 3 transition by introducing so many breaking changes. Instead, they have a…

"The devs are users themselves, and they hate breaking changes too."

Sure. That's the point: e.g. back in the day UTF-8 was invented for allowing Unicode support without breaking API compatibility. I ask for thinking 10.000 times before breaking backwards compatibility.

Re: Python 2.7 Countdown

#64

Post by redsymbol »

Walkman wrote: post #59
redsymbol wrote: post #44

I teach online workshops on intermediate Python to several hundred developers each month, scattered globally. Since these are engineers in the work force, I start each class with a quick poll about which version they primarily use on their jobs: 2.7, or 3.x. 18 months ago, the results were typically 20% Python 3, and 80% Python 2. Over time, the ratio shifted. In recent months, it's VERY consistently 60-70% Python 3;…

Who on Earth would write "Python2" in their resume? I have "Python".

I mean this in the kindest possible way:

You're taking what I wrote too literally, and thus missing the point. What I wrote means: if the only Python you know is 2.x, it might close off opportunities for you in the near future.

Re: Python 2.7 Countdown

#65

Post by kstrauser »

hungerstrike wrote: post #54
kstrauser wrote: post #40

Earlier quoted context omitted.

At some point a CFO will ask why a company is spending $X to use ancient, unhireable versions of their tools when new, free, attractive versions exist. It will be explained - not exactly in these words - that it's basically because their senior devs refuse to learn new stuff. Senior management arguments will ensue. At the end, there will be a plan to save $X with One Simple Trick. Displaced senior devs will find them…

Python 3 has been out for how long? None of this has happened yet. What is going to make 2.7 so unmaintainable? It’s there, it works and what is going to change that?

Python 2.7 is currently supported. It's not a great idea, but at least defensible, to still be developing against it today. But the moment it becomes officially obsolete and shops have to justify paying special support contracts to maintain it, I think it'll become very hard to explain why that's a good business decision.

There are valid reasons for using 2.7 today. I think it's professional negligence to not at least be planning for the inevitable upgrade to the current version. Honestly, it's almost never as hard as you'd think. The most common hurdles are str/bytes incompatibility, and 3.x only reveals those problems where they already exist in 2.x (where the code is quite possibly not working as expected but silently passing wrong data without warning you).

Re: Python 2.7 Countdown

#66

Post by eesmith »

toyg wrote: post #60
eesmith wrote: post #43

Earlier quoted context omitted.

Because "lag" implies that Apple is going to catch up, which is not the case. jeremiep's response is that Apple won't ever (under current management) update to GPLv3. It's not a lag, it's a deliberate avoidance.

They've always been slow, even when licensing was not an issue. OpenSSL is not GPL3. They still shipped a very old version, then apparently switched to LibreSSL... and promptly shipped an old version of that. They lag. Licensing is an issue for a subset of tools, but lagging is very much an issue for all of them.

Thanks for the correction. Indeed, OpenSSL is not under the GPL.

Re: Python 2.7 Countdown

#67

Post by kstrauser »

yegle wrote: post #48

I took some time try to make an old codebase to work with python2/3. Some wat moment from the effort: 1. `StringIO.StringIO` is a PITA. There's no equivalent in Python3 (for a good reason), and you must choose between `io.StringIO` (which only support unicode) and `io.BytesIO` (which only support bytes string). A possible solution is to use `six.StringIO` but it's simply bury the problem. It would be a good idea to t…

I think those are all improvements in Python3, even if they can be a hassle to fix:

1. Lots of legacy code incorrectly treats strings and byte arrays as the same thing. If you're dealing 100% with all ASCII all the time that might be mostly OK, but it's the wrong model for anything involving Unicode (which is pretty much everything now).

2. Modes are defined on Linux and macOS at least as uint32_t. -1 isn't a valid value of that type.

3. That bit me a few time. I've accepted that `def foo(a, b_and_c, d): b, c = b_and_c` is an alright substitute.

4. I like the new version better. `'a' > 5` doesn't even make sense and the 3.x way avoids accidental nonsensical comparisons.

Re: Python 2.7 Countdown

#68

Post by hungerstrike »

kstrauser wrote: post #65
hungerstrike wrote: post #54

Earlier quoted context omitted.

Python 3 has been out for how long? None of this has happened yet. What is going to make 2.7 so unmaintainable? It’s there, it works and what is going to change that?

Python 2.7 is currently supported. It's not a great idea, but at least defensible, to still be developing against it today. But the moment it becomes officially obsolete and shops have to justify paying special support contracts to maintain it, I think it'll become very hard to explain why that's a good business decision. There are valid reasons for using 2.7 today. I think it's professional negligence to not at leas…

> But the moment it becomes officially obsolete and shops have to justify paying special support contracts to maintain it...

Who even pays for a support contract for programming language that’s already done?

That’s like saying JavaScript is unusable because of all of the different versions. Nobody has to pay anybody to use ES3 even though it’s largely obsolete.

Re: Python 2.7 Countdown

#69

Post by Walkman »

redsymbol wrote: post #64
Walkman wrote: post #59

Earlier quoted context omitted.

Who on Earth would write "Python2" in their resume? I have "Python".

I mean this in the kindest possible way: You're taking what I wrote too literally, and thus missing the point. What I wrote means: if the only Python you know is 2.x, it might close off opportunities for you in the near future.

Oh ok, that makes sense.

Re: Python 2.7 Countdown

#70

Post by mkesper »

cesarb wrote: post #46
alergico wrote: post #10

Guess the community (or a company like RedHat) will have to step in and fork 2.7. There is no way that people who haven't switched, will want to switch, unless absolutely forced to (for example: no security patches).

I expect RedHat to continue to support Python 2.7 for as long as major RHEL versions which came with are still under support. I also expect major RHEL versions released after Python 2.7 is EOL to not come with Python 2.7 anymore. That is, if RHEL 8 is released before the Python 2.7 EOL, and RHEL 9 is released after the Python 2.7 EOL, I expect RHEL 8 to come with both Python 2.7 and Python 3, with RedHat supporting b…

But they cannot support the whole Python environment for Python2. Many projects (django etc.) drop Python2 support after April 2020.
Post reply on HN