Live data from Hacker News

Python 2.7 Countdown

pythonclock.org

41–50 of 72 posts

Re: Python 2.7 Countdown

#41
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 ;)

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.

Re: Python 2.7 Countdown

#42
post #7

"…hereby suggesting we throw a massive party to celebrate all that Python 2 has done…" Perhaps it's that ominous counter, but these words really evoked Poe's "The Masque of the Red Death" for some reason.

I think of it more like a wake.

In "The Masque of the Red Death" they shut themselves away from the rest of the world. There's no correspondence from that to the end of core developer supported Python 2.

Re: Python 2.7 Countdown

#43

Earlier quoted context omitted.

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 ;)

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.

Re: Python 2.7 Countdown

#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; one class it was 80%.

As I tell those students: sooner than you think, having only Python 2 on your resume will make it look dated.

Re: Python 2.7 Countdown

#45
post #43

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

Doesn't imply that to me. To me, lag is just that they're behind, regardless of reason. It is lag and deliberate avoidance. Please stop assuming what people don't understand or are implying.

Re: Python 2.7 Countdown

#46

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 both until RHEL 8 support ends, but RHEL 9 to come with only Python 3; so once RHEL 8 dies, RedHat has no reason to support Python 2.7 anymore.

Re: Python 2.7 Countdown

#47
For those still running 2.7 because migrating is too hard, consider using my "ppython" version (https://github.com/nascheme/ppython). It is a modified version of 3.6 with extra backwards compatibility features. After running your code through 2to3, it should mostly work with ppython. After fixing all the runtime warnings, your code should work with regular 3.6.

Re: Python 2.7 Countdown

#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 think about what string you are dealing with before doing any change around StringIO.

2. The `stat` module contains some helper functions to test st_mode. In Python2, the function will happily accept negative numbers but in Python3 an exception will throw:

  $ python2 -c 'import stat; print(stat.S_ISDIR(-1))'
  False
  $ python3 -c 'import stat; print(stat.S_ISDIR(-1))'
  Traceback (most recent call last):
    File "", line 1, in 
  OverflowError: can't convert negative value to unsigned int
3. You can do `def foo(a, (b, c), d)` in Python2: https://www.python.org/dev/peps/pep-3113/

4. You can compare slice with int in Python2:

  $ python2 -c 'print(slice(1) > 1)'
  True
  $ python3 -c 'print(slice(1) > 1)'
  Traceback (most recent call last):
    File "", line 1, in 
  TypeError: unorderable types: slice() > int()

Re: Python 2.7 Countdown

#49
post #36
post #32

Earlier quoted context omitted.

> Like with any other system where some old version just won't go away, the ones who absolutely will not switch to Python 3 will eventually (literally) go extinct. And yet there are tons of lines on COBOL in active use today. What makes you think 2.7 code, which powers tons of businesses, is going anywhere?

At some point in the future the cost of maintenance vs. cost of rewriting/upgrading will be so much in favor of the latter that businesses will make the (correct) choice to "go with the times" instead of spending an ever increasing amount of money and time on maintaining a code base `x` years old written in a language not officially supported/extended for `y` years, experts for which are increasingly rare (and thus e…

If they can find Cobol experts 50+ years after the original programs were written, they'll have no issue finding 2.7 experts 50+ years on, especially since 3 and 2.7 and more alike than different.

Re: Python 2.7 Countdown

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

Doesn't imply that to me. To me, lag is just that they're behind, regardless of reason. It is lag and deliberate avoidance. Please stop assuming what people don't understand or are implying.

If we have a race, and I stop half-way through, hit the lockers, change, and leave, would you say I'm lagging?

In the most recent Vendée Globe around-the-world sailing race, 11 people did not finish. https://en.wikipedia.org/wiki/Vend%C3%A9e_Globe#2016%E2%80%9... . Do you say they are lagging?

Some people start to hike the Appalachian Trail, stop part-way through, and decide to move to/live where they stopped. They never finish the trail. Are they lagging?

Why do you assume that you know what toyg means by "lag"?

Post reply on HN