If there is Python 4, please, make it backwards compatible. Thank you.
A major version bump does tend to imply breaking changes.
Python 2.7 Countdown
51–60 of 72 posts
Re: Python 2.7 Countdown
#52I made a similar, albiet more vulgar website a while ago: http://stfupy3.org/
Re: Python 2.7 Countdown
#53Re: Python 2.7 Countdown
#54Earlier quoted context omitted.
Pffft. Nice strawman. Who said it would be free or easy? Expecting that everyone will just hop over Python 3 because one group of people doesn't want to maintain Python 2 anymore is delusional.
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…
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?
Re: Python 2.7 Countdown
#55Re: Python 2.7 Countdown
#56Earlier quoted context omitted.
A major version bump does tend to imply breaking changes.
Why?
Re: Python 2.7 Countdown
#57Earlier quoted context omitted.
Why?
What exactly does the term "major version update" mean to you if not for a break in backwards compatibility? That's what a major version update is .
My point was: I expect Python 4 avoiding the mistakes of Python 3 regarding breaking backwards compatibility. Just that.
Re: Python 2.7 Countdown
#58If there is Python 4, please, make it backwards compatible. Thank you.
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+
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 the risk.
P.S. I like Python. What I don't like is the 2.x to 3.x transition, and the risk of happening a similar thing again.
Re: Python 2.7 Countdown
#59I 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;…
Re: Python 2.7 Countdown
#60Earlier quoted context omitted.
What makes you think GP didn't understand the context? I don't get why people bash other people for saying objective truths just because they think the other person doesn't understand why. If they can't/won't ship up to date third party software, they shouldn't ship the third party software at all.
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.
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.