Sunsetting Python 2

Post by Drdrdrq » Tue, Sep 10, 2019, 5:20 AM UTC

jsjohnst wrote: post #168

toyg wrote: post #120

Earlier quoted context omitted.

Somebody has done just that already, it’s easily googleable. Nobody really cares though - why would you purposefully tie yourself to an objectively-inferior featureset, full of problems that have already been solved in py3? Because you can’t bear the use of parentheses for print, really?

> Because you can’t bear the use of parentheses for print, really? While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.

Post by greglindahl » Tue, Sep 10, 2019, 5:48 AM UTC

ilikehurdles wrote: post #473

privateSFacct wrote: post #453

Earlier quoted context omitted.

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.

This is such a good analogy, and really highlights the point that python 2 stalwarts look at organizations hiring for FORTRAN and COBOL today, and say to themselves, "Yes, this is the kind of organization I want to build." An organization that will either (most likely) be completely irrelevant in 10 years time or have to pay a massive premium salary for any engineer that can maintain their systems.

Post by [deleted] » Tue, Sep 10, 2019, 5:57 AM UTC

radus wrote: post #522

mikepurvis wrote: post #284

Earlier quoted context omitted.

Quick: run a shell command, split up the reply by line, run a regex on each line, and save the results to a yaml file— now, does what you wrote work correctly on both Python 2.7 and Python 3.3+? Yeah that's what I thought. It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.

Okay, I did it. import subprocess import re import yaml output = subprocess.check_output(['ls', '-l'], universal_newlines=True) matching_lines = [] for line in output.splitlines(): if re.search(r'total', line): matching_lines.append(line) with open('matching_lines.yaml', 'w') as f: f.write(yaml.dump(matching_lines)) Python 3.7: https://repl.it/repls/PotableDamagedAutocad Python 2.7: https://repl.it/repls/OrchidDirtyN…

Post by PhantomGremlin » Tue, Sep 10, 2019, 6:39 AM UTC

salamanderman wrote: post #304

My new Mac laptop in 2016 came installed with Python 2.7 from Apple. It's that kind of subtle defaults that I think slowed the transition. I didn't want to change the system Python.

Post by comex » Tue, Sep 10, 2019, 7:41 AM UTC

WorldMaker wrote: post #546

pnathan wrote: post #515

Earlier quoted context omitted.

The Py3 string handling was beyond frustrating prior to 3.6. For what I do, Unicode complexity is not required. Having to stuff it into everything was more trouble than it was worth.

The ubiquity of emoji alone mean that Unicode is everyone's problem in 2010+, and ignoring it won't make it go away. It's Python 2.x where dealing with Unicode (which is everywhere) is far too complex, and more trouble than it is worth. The "complexity" of Python 3 string handling is worth it, and no worse (even < 3.6) than any other modern programming language, and possibly easier than some by making clear runtime e…

    % python3.7 -c "import sys; print(sys.argv[1])" "$(echo -e '\xff')"           
    Traceback (most recent call last):
      File "", line 1, in 
    UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 0: surrogates not allowed