Live data from Hacker News

Sunsetting Python 2

python.org

661–670 of 733 posts

Re: Sunsetting Python 2

#661
post #490

What I hate about this document is part of a bigger problem I see with the Python community. It's written like a hate letter with a passive aggressive tone of finger pointing towards users of Python as the source of the never-ending Python 2-3 split. It says, between the lines: "YOU are part of the problem, stop using Python 2. We don't care about YOU anymore. Stop using Python 2". I can think of ten other different…

It's been 10+ years, they're just being a matter of fact.

Re: Sunsetting Python 2

#662

Earlier quoted context omitted.

It's not "broken"... Python3 is just the evolution of the language. Languages change and evolve, some more and some less than others. Sure, Java or COBOL maybe have done a better job of not breaking backwards compatibility, but Python 3 isn't exactly Perl 6 here. But hey, if some 3rd party group effectively forks the language and maintains a Python2 branch after the official EOL date, good on them. But I'd argue that…

> It's not "broken"... Python3 is just the evolution of the language. Python3 broke compatibility for spurious reasons. The language didn't change that much, it could have kept compatibility with minor concessions. > Java or COBOL maybe have done a better job of not breaking backwards compatibility... Literally every single other major language has done a better job at it. That's a big part of why they are major lang…

> Literally every single other major language has done a better job at it.

C++'s upgrade woes make Python 3 look downright trivial in comparison.

Re: Sunsetting Python 2

#663

Earlier quoted context omitted.

Likely the case. A lot of foot dragging took place. By five years ago most things of use were py3, conversion was easier than ever (and easy enough). More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here. That people are still writing new py2…

the RHEL vm's that I get at my job (enterprise IT) have python2 installed by default and no python3. It is much simpler to write scripts in python 2 (albeit written in a way to support forward compatibility with 3) because python2 is just there by default on every VM and its one less requisition order to write. We are actually upgrading to python 3 at the end of this month, but we lived with python 2 for a full year.…

Well, it seems you were writing py3 code in py2, as much as was possible, so I wouldn't lump you in yo the criminal camp.

Not everywhere had that foresight.

Re: Sunsetting Python 2

#665
post #662

Earlier quoted context omitted.

> It's not "broken"... Python3 is just the evolution of the language. Python3 broke compatibility for spurious reasons. The language didn't change that much, it could have kept compatibility with minor concessions. > Java or COBOL maybe have done a better job of not breaking backwards compatibility... Literally every single other major language has done a better job at it. That's a big part of why they are major lang…

> Literally every single other major language has done a better job at it. C++'s upgrade woes make Python 3 look downright trivial in comparison.

What are you talking about? C++ has had very few breaking changes in the language.

If you're talking about ABI breaking, that's a different story. Python breaks the ABI in every major release as well. That generally requires a recompile, not a major code migration.

Re: Sunsetting Python 2

#666
post #522

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…

This program would crash with a UnicodeEncodeError upon encountering any file with a non-latin character in its name on Windows with Python 3.5 or earlier.

I know that's not the version of Python you were targeting, and I know you didn't write this program to be cross-platform, but I wrote a similar program and I was repeatedly surprised by those sorts of problems. I don't entirely agree with mikepurvis, but I do feel his pain.

Re: Sunsetting Python 2

#667
post #656
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…

> (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...) Isn't what code review and CI/CD is for?

Isn't force-merging without waiting for code review or test results what managers are for?

Re: Sunsetting Python 2

#669
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…

Let me put it this way: at $dayjob, where 'IT' isn't particularly specialized, we just celebrated a switch to SQL Server from a homegrown database written in the early 80ies.

I wager that in many cases, fixing something that isn't broken never reaches the top of the TODO.

Post reply on HN