If it weren't a forced update, I personally have not found much in Python 3 that is a benefit over 2. It seems the unicode support is the big change, but I just use ASCII encoding, so unicode doesn't matter to me.
Sunsetting Python 2
521–530 of 733 posts
Re: Sunsetting Python 2
#522Earlier quoted context omitted.
But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.
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 2.7: https://repl.it/repls/OrchidDirtyNotification
Re: Sunsetting Python 2
#523Earlier quoted context omitted.
By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones.…
“unless there are reasons the porting is difficult, it’s easy” thanks, chief. genius stuff there
"Unless there are very rare reasons the porting is difficult, it's easy" is closer to what he actually wrote.
Re: Sunsetting Python 2
#524Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curat…
Out of curiosity, what is it that you like about Python 2? Not attacking you, just curious. I've never used Python professionally (mostly Ruby and Clojure), so I don't have a horse in this race.
I just realized I didn't answer your actual question, sorry.
> what is it that you like about Python 2?
I came from C and Pascal so from that POV Python is a rich and delicate syntactic and semantic gravy over the same basic functionality plus shell (Python was originally the shell language of the Amoeba distributed OS†).
Things that might not seem that big a deal these days were a revelation to me when I started with Python:
- The basic datatypes, list, tuple, and dict, are enough to describe so much of the tasks you need to do.
- Slice notation is so useful, and works on the left-hand side (you can assign to slices) and the elegance (you can reverse a string or list or tuple by oof = foo[::-1].)
- The simple but effective OOP model, "dunderscore" methods, monkey-patching is possible.
- How can I forget! Indentation for blocks! So crazy but it works so well.
- long ints that don't overflow! So nice.
I can go on but really it was the whole thing, the syntax, the semantics, the standard lib. But in my opinion it reach a zenith sometime between 2.4 and 2.7, and even then Python overgrew its ecological niche. (What I mean is that if your project has more than 100,000 lines of Python you're pretty much fucked, but people do that all the time these days. I once worked on a horrible old "lava-flow" enterprisey Python codebase that could have been replaced by Excel but instead employed a gang of programmers. Pure waste.)
Re: Sunsetting Python 2
#525Earlier quoted context omitted.
"Hey boss, we're gonna use this hip new language that will break everything for no good reason a few years down the line." Congratulations. You're fired.
"Hey Joe, why did our customer database get leaked and published on a dark-net site?" "Hey boss, we're using an outdated programming language for which security updates are no longer provided, because we were told there's no budget for fixing technical debt." "Congratulations, you're fired." Same outcome either way... might as well make some effort to do the right thing along the way...
You're missing the point. If decision makers saw it coming that Python will just break in two, they would have never allowed its use. Other "serious" programming languages rarely if ever break, and when they do, it's usually minor.
Python2 will almost certainly still remain in widespread use and it will still get security updates through alternative distribution channels. It's not that much work fixing such relatively rare issues versus migrating a major codebase.
Re: Sunsetting Python 2
#526If it weren't a forced update, I personally have not found much in Python 3 that is a benefit over 2. It seems the unicode support is the big change, but I just use ASCII encoding, so unicode doesn't matter to me.
> but I just use ASCII encoding
No you don't! :D
Re: Sunsetting Python 2
#527Earlier quoted context omitted.
This is a bit and oversimplified, but it also seems a bit weird, to me, to respond to a situation of "man it's going to be really annoying to rewrite all this code" with "You know what sounds like a better option? Rewriting all this code!"
I think a fairer interpretation of the situation is "Well, we have to rewrite and test all this code anyway, so the barrier to picking another language to go forward with is quite low right now."
That's a corollary to this, for sure, particularly if there's another language that would be more appropriate. That said, the OP seemed to be moving on primarily out of annoyance. Assuming that's the case and Python is the best language for the project (keeping in mind things like "I can hire the same quality people who WANT to work in this language), I stand by my (still slightly tongue in cheek) position.
Re: Sunsetting Python 2
#528Earlier quoted context omitted.
IBM does quite a good job of making sure that COBOL is supported long term with all needed updates for many many years to come. Python 2 is not in that position.
You mean, IBM does quite a good job of making sure IBM COBOL is supported long term. They are maintaining their compiler, which is exactly what PSF is doing. They are maintaining their interpreter, which is Python 3.
The GP post missed the fundamental difference between keeping COBOL running and keeping Python 2 running. Python 2 was also PSF's interpreter. IBM handling a COBOL upgrade like PSF handling the 2-3 transition would be unacceptable.
Re: Sunsetting Python 2
#529Python 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…
One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came…
> 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.
The post you're responding to starts verbatim with `Python 2 to 3 (at least by 3.3 or so)` and your reply is about Python 3.1, released 3 years earlier. The amount of changes was quite big.
Re: Sunsetting Python 2
#530Earlier quoted context omitted.
I would have said Java, but then they decided to shove modules down everyone's throat.
I would say the Perl but then the Perl 6 fiasco made Python 3 look like a model citizen for upgrading code.
Perl5 is not being EOL'ed in favour of Perl6. When the time does come around for Perl5, I would guess that only a small fraction would migrate to Perl6.