Well, speaking only for myself, if I think of Python 3 as a separate language from Python 2 (which it surely is by now) and ask myself as a sober, grounded, (wannabe) engineer "what do I gain from (re-)writing my code in Python 3?", I gotta say the benefits just aren't there.
There's nothing technically compelling in Python 3. It's all developer candy.
Python 2 is going to remain stable for years, even decades. It's FORTRAN. Development on the C interpreter will stall, but what that really means is that it will become asymptotically bug-free. If no one is touching the code except to apply bug-fixes there are no sources of new bugs (okay bug-fixes will introduce bugs themselves, but the net trend will be negative.)
Even if you have to use e.g. Tauthon (a Python 2 that brings in a few select features from 3) you can still expect a more stable environment than Python 3 development.
And there are a lot of Python 2 runtimes and other places where Python 2 syntax is still welcome: Stackless, Pypy, Cython, Nuitka, MicroPython, Brython, etc... Python 2 hasn't gone anywhere.
Frankly, I think it's a damn shame IMHO that the Python 3 interpreter can't run Python 2 code! Not even with a command line switch. It should be able to switch syntax per module/file at least.
Anyway, to repeat, to me Python 3 is full of dubious toys for developers but has no compelling business value to drive adoption. It's cannibalizing the Python 2 community and ecosystem, but without that nobody would use it. It's not better than 2, just different.
If you were to start a new project and had to decide on a language, you would be better off (IMHO) with Rust or Go (or Python 2) than Python 3, generally speaking.
Let me turn the question on it's head: Python 3 adopters, can you give me a reason, a technical reason, why I should chose P3 over P2 for any project?
I'll throw out some things right off:
Performance. No. If you're using Python and worried about performance you've already committed stupidity and I'm not interested. Cython is your friend.
Async. No. I write Twisted code. Async has been done. Adding keywords to the language is stupid. (As an aside, I know Twisted is hard to use, and the docs sucked until recently, but it is a damn fine code base, written by really good and committed people, and it's an unsung under-appreciated treasure chest! Any Python networking code that does anything serious and doesn't use Twisted is probably doing too much work, poorly. The last thing the language needed was "async" as a keyword. "Foooooootguuuuuuun Jenkins!")
F-strings. No. More stupid and there are dozens of libs that do it.
Support? No. I can maintain the P2 code on my own if need be, but I don't need to because there are others, e.g. Tauthon, etc.. and I can support them. Plus as I said above, with no innovation comes no new bugs!
Type hints et. al. Ummm..., No. I was really stoked about this, but the first time I tried to use it (MyPy) I immediately broke it. I was doing things with the default keyword argument dict that just couldn't be represented in the type language. Valid useful Python code that the types can't handle is a thing. I like strong types, but Python has never benefited from over-nicety in typing. Quack, quack. Put another way, the coercive-type subset of Python is great but overly restrictive. (Which is not inherently bad, I think Elm-lang is brilliant!)
I love Python 2 because it has such a clean syntax, it deals sensibly with all the little fiddly bits that e.g. C makes you think about, and its semantics are powerful and flexible but elegant enough that you can hold the model (or a reasonable homologue) in your head.
From my POV Python 3 just messes up 2. I see no compelling technical reasons to use 3.
mypy has gotten a lot better and I wouldn't discount it because of one bad use case. I went through the exercise of applying type hints to a large code base and uncovered several latent bugs.
That being said, mypy supports type hints in Python 2 code, so that really just adds to your argument.
I want to be clear, I like MyPy and the whole type-hints in Python thing, but it's not good enough to make Python 3 compelling to me.
I was doing something that was totally "plain vanilla" in the Python semantics but outside the assumptions of the type checker.[1] It made me realize that "strictly-typed" Python is a subset of actual Python. It's not that "strictly-typed" Python isn't a useful language, it's that if I really wanted strict typing I'd use e.g. Haskell or Elm, where you get so much more bang for the buck it's not even funny.
"Duck-typing" is a trade-off. In that sense, strict typing actually kinda weakens Python 3, because you're losing [the full advantage of] duck-typing but not gaining [the full advantage of] strictly-enforced type-checking and type inference. And, as you point out, the lesser advantages of type hints are available to Python 2...
[1] I was experimenting with a purely functional web template sytem and I was using the keyword args dict as a sort of "grab bag" of values that functions could pass around, picking out the values they were "interested in" by named keyword parameters. It worked fine but there was no way to tell MyPy what the type of the dict should be.
>Python 3 adopters, can you give me a reason, a technical reason, why I should chose P3 over P2 for any project?
Perhaps not yet, but soon enough, sure.
The year is 2025. You want to set up a webserver to do something in python2. The Letsencrypt api doesn't have official python2 bindings, SQLAlchemy hasn't provided any database interfaces for python2 in 6 years, and so you can't use recent versions of postgres without writing your own dbapi.
There's been a couple of major security bugs found in various system tools, and sane flags and defaults have changed as a result, but python2's standard library never updated to call them safely, so you're default insecure. And libraries like smtp and BaseHTTPServer don't support modern standards like HTTP3 and extended MIME types.
You're banking on all that maintenance being easier than porting to python3.7 or whatever (which in my experience is actually very easy once you know what you're doing, you can port a decently sized project in a day or so).
> The year is 2025. You want to set up a webserver to do something in python2. The Letsencrypt api doesn't have official python2 bindings, SQLAlchemy hasn't provided any database interfaces for python2 in 6 years, and so you can't use recent versions of postgres without writing your own dbapi.
Am I the only person still using Python 2 and LetsEncrypt? SQLAlchemy? Postgres? I try to keep to a minimal dependency graph. Even so, writing "glue code" in Python 2 will still be easy, and API description languages like e.g. Swagger will only become more common, so I'm not worried about being left in an incompatibility cul-de-sac.
(And if I am the only person still supporting Python 2 in seven years I'm probably raking in dollars in legacy support contracts, no? You know COBOL programmers make bank, eh?)
> There's been a couple of major security bugs found in various system tools, and sane flags and defaults have changed as a result, but python2's standard library never updated to call them safely, so you're default insecure.
First, do you have links or other references? I'd really like to read up on those.
Second, yes, the standard library needs an overhaul (and the docs are soooo bad to this day.) You got me there. One of my dreams has been to start a "Python Unstandard Library" (sic) and comb through all the existing Python 2 libs and make a really clean and well-documented, uh, library. That's probably not going to happen. That said, back-porting bugs and security fixes from Python 3 is something that still has to be done and I'm one of the people who intends to do it.
So yeah, more free other people's work is one reason to prefer 3 to 2 (if it turns out that way. As in a lot of crucial open source projects, the Python core maintainers are not a large nor well-paid group...)
> And libraries like smtp and BaseHTTPServer don't support modern standards like HTTP3 and extended MIME types.
Networking in Python to me means Twisted. Now if they abandon Python 2 I might have a problem, however, I wouldn't write a webserver in Python for love or money. Python (neither 2 nor 3) is not a great language for high-performance backend servers. (I know that doesn't stop people from doing it.) I would probably use Go. Or write your prototype in Python and then rewrite in Java or C++ if you get funded.
And, to repeat my earlier argument, am I the only person using Python 2 in 2025 who has to use HTTP3?
> You're banking on all that maintenance being easier than porting to python3.7 or whatever
Yep, I sure am. I'm not the only person who feels this way. I'm banking that enough momentum remains in the Python 2 ecosystem and community to keep supporting it for at least twenty to thirty years (if there's nothing better before that I'm going to give up computers.) Heck, we're probably going to see 2.4 in the wild til forever too.
People are trying to kill Python 2 and it's not working. Adding in B.S. like PEP 572 only makes it harder to kill.
>Am I the only person still using Python 2 and LetsEncrypt? SQLAlchemy? Postgres?
When the alternative is to use officially supported versions with minimal work, yes. You're likely one of the few people using them, or you're paying someone to do it for you. Like if you're willing to pay someone for support then that's fine, but its not like this is going to be free.
>First, do you have links or other references? I'd really like to read up on those.
We're talking about a future. But python seems to average ~2 CVEs per year, which is a great track record, but means you'll have 10 unpatched vulnerabilities by 2025.
>Networking in Python to me means Twisted.
Ok, that's fine. Do you think the twisted devs are going to support a deprecated python version for 5 years? Especially since the majority of their work recently has been to fully support python3? The writing is on the wall.
>Heck, we're probably going to see 2.4 in the wild til forever too.
Where do you see any open source projects that are compatible with python2.4? (it didn't support `with` or conditional expressions). Sure there's code still running that's written for python 2.4, but its code that was written at $SOMECO 15 years ago and hasn't been touched since. Sure that exists, but that's not a particularly enviable situation.
>am I the only person using Python 2 in 2025 who has to use HTTP3
I mean probably. That's the entire point of using modern, supported tools. They get support and keep up to date with modern technology. There aren't a whole lot of Java 5 compatible libraries that support HTTP2. That's the price you pay for using unsupported legacy software: not being able to use modern technology.
>Adding in B.S. like PEP 572 only makes it harder to kill.
Ah yes, entirely backwards compatible changes truly make it impossible to upgrade! I'm not particularly a fan of PEP 572 (in fact I actively dislike it), but this is just nonsense.
> You're likely one of the few people using them, or you're paying someone to do it for you. Like if you're willing to pay someone for support then that's fine, but its not like this is going to be free.
It was kind of a rhetorical question. I know I'm not alone. Anyway, if I'm still doing Python at all in a few years I'll be willing to pay people to work on 2, or likely be one of the guys getting paid to support other folks' legacy (or fresh) Python 2 code.
But I already admitted getting more free work from other people is a reason to prefer 3 to 2.
> 10 unpatched vulnerabilities by 2025.
I can handle that. (I mean I can patch P2.)
> Do you think the twisted devs are going to support a deprecated python version for 5 years?
Maybe. But I know they aren't going to destroy the P2 code, and I can patch it if I really need it. It won't be that hard to back-port from 3 to 2, will it?
But again, I don't like Python for network code. I would use something else. If I really really wanted to write non-prototype network services in Python I would probably embed the interpreter in some other solid server to do the heavy lifting and just use Python to write the dynamical bits. But then I would probably just use Lua. Or write the thing in Erlang! What I'm saying is, if I had to choose a language in 2025 to write a server and my choices are Python 2, Python 3, or any other language, my answer is not going to be Python 3 or 2.
> Where do you see any open source projects that are compatible with python2.4?
On PyPI. But that's not my point. My point is that even 2.4 hasn't disappeared yet. There's going to be a "long tail" if you will of P2 in service.
> Sure that exists, but that's not a particularly enviable situation.
You do realize I'm not being conservative for its own sake, eh? I don't envy anyone stuck maintaining a 2.4 codebase, but I also don't envy the folks who have to wrangle with P3.
> That's the price you pay for using unsupported legacy software: not being able to use modern technology.
I just don't think that that price is going to be too high in the case of Python 2. I'm hopeful that there will remain enough critical mass to carry it forward even after official support ends and even with all the effort to deprecate it.
In fact, I think the effort to deprecate it is kind of rude, and a better way of going about the whole thing would have been to have the P3 interpreter support P2 code and let conversion to 3 be driven by its merits. The incompatibility was a choice, and I think it's the wrong choice.
Let me ask you this: If someone else, other than Guido, had come forth with a project called e.g. Python++ (just P3 but with a different name) and tried to get people to use it, how well do you think adoption would go? People would only use it if it had some seriously compelling features, eh? I mean people barely notice Stackless Python and Cython (just two examples of Pythons with extra abilities and compelling use cases) so do you think folks would flock to Python 3 if the BDFL weren't pushing it while simultaneously deprecating Python 2?
All I'm really saying is, if you think of P3 as a separate project, and pretend that P2's wind-down is just a coincidence, then it makes total sense to make arrangements to keep supporting and using P2. (Especially if, like me, you prefer it.) I don't think it will take that much to keep a fork project viable (Tauthon or whatever) since it would eschew changes and just be maintenance upkeep. It's not the first time users have forked a legacy project to keep it alive after the originating body abandoned it.
Lastly, when I said "PEP 572 only makes [Python 2] harder to kill." I meant that it makes people like me double-down on our commitment to Python 2. "From my cold, dead hands!" and like that.
>but I also don't envy the folks who have to wrangle with P3.
What wrangling is there?
>All I'm really saying is, if you think of P3 as a separate project, and pretend that P2's wind-down is just a coincidence
This is an unhelpful comparison. The same thing is true for approximately any feature for any open source project. Would a fork of go which adds generics take mindshare despite being "better"? No! (such forks exist). But that doesn't preclude the official Go implementation from adding generics.
>The incompatibility was a choice, and I think it's the wrong choice.
I'll repeat that most of the code that I write is python3.6 and python2.7 compatible. The only incompatibilities are things that are essentially bugs in python2/not fully specified (unicode vs. string handling), and then a bunch of additional features. It took me all of 3 hours to port a relatively meaty python2.6 application to being 3.6 and 2.7 compatible (and it was a hell of string + unicode nonsense). All it requires is good tests and some dedication, and porting is really, really easy. People just don't seem to believe that.
>It won't be that hard to back-port from 3 to 2, will it?
Worst case for you: twisted begins to support asyncio and rely on python's own event loop. Then twisted code magically gets async/await support in python3 and backporting features becomes potentially impossible.
> > but I also don't envy the folks who have to wrangle with P3.
> What wrangling is there?
Every time a PEP modifies the syntax or semantics (e.g. ordered dicts for class namespaces) any project that wants to conform to Python 3 has to "wrangle" those changes into their thing. There are more Pythons than the C Python, not to mention tools like Snakefood[1]. That's in addition to "wrangling" with new bugs introduced into the interpreter while adding support for new features, and with the new sources of bugs that the new features and syntax enable.
A stable unchanging Python 2 doesn't engender any of that overhead. You just have to fix bugs and security, uh, bugs.
> > All I'm really saying is, if you think of P3 as a separate project, and pretend that P2's wind-down is just a coincidence
> This is an unhelpful comparison.
Unhelpful to whom? I'm trying to explain my reasoning around sticking to Python 2 and that's how I look at it. It doesn't matter to me that the BDFL is the one pushing this, as much as I like him he's not an actual dictator. He's pissing in my soup and I don't mind saying so. (Yes, he made the soup in the first place but some of it's in my bowl now and he can't have it back.)
> The same thing is true for approximately any feature for any open source project. Would a fork of go which adds generics take mindshare despite being "better"? No! (such forks exist). But that doesn't preclude the official Go implementation from adding generics.
I don't understand. P3 isn't a fork which adds a few features, that's Tauthon. P3 is a different language that's almost-but-not-quite Python 2.
I'm not saying Python 3 shouldn't exist, that's a separate argument I'm not making. What I'm saying is given a choice between stable Python 2 with a decaying maintenance cost and Python 3 with its open-ended maintenance cost and no compelling technical reasons to adopt it, well, I'm sticking with 2.
> > The incompatibility was a choice, and I think it's the wrong choice.
> I'll repeat that most of the code that I write is python3.6 and python2.7 compatible. The only incompatibilities are things that are essentially bugs in python2/not fully specified (unicode vs. string handling), and then a bunch of additional features. It took me all of 3 hours to port a relatively meaty python2.6 application to being 3.6 and 2.7 compatible (and it was a hell of string + unicode nonsense). All it requires is good tests and some dedication, and porting is really, really easy. People just don't seem to believe that.
You're not wrong, I've done it too. But all I got out of it was Python 3 compatibility... So far your best argument for conversion is "people will support it" and I keep telling you "people will support Python 2 too".
But the incompatibility I'm referring to there is the one I mention in the preceding sentence: "a better way of going about the whole thing would have been to have the P3 interpreter support P2 code and let conversion to 3 be driven by its merits." The Python 3 interpreter should run Python 2 as well. That's the "choice" I think was wrong.
> Worst case for you: twisted begins to support asyncio and rely on python's own event loop. Then twisted code magically gets async/await support in python3 and backporting features becomes potentially impossible.
That actually made me laugh out loud. Cheers. But that still wouldn't break their existing code. And again, I wouldn't use Python for [cutting edge] networking. I've done it. It's good for prototypes.
Look, maybe there will come a day when there's some P3 lib I just have to use in one of my projects and it's somehow just so stitched into the Python 3 that I can't backport it or imitate its magic in Good Ol' Two. If that day comes, well, "porting is really, really easy". ;-)
(It's been really fun discussing this with you today. Cheers and warm regards!)
There's nothing technically compelling in Python 3. It's all developer candy.
Python 2 is going to remain stable for years, even decades. It's FORTRAN. Development on the C interpreter will stall, but what that really means is that it will become asymptotically bug-free. If no one is touching the code except to apply bug-fixes there are no sources of new bugs (okay bug-fixes will introduce bugs themselves, but the net trend will be negative.)
Even if you have to use e.g. Tauthon (a Python 2 that brings in a few select features from 3) you can still expect a more stable environment than Python 3 development.
And there are a lot of Python 2 runtimes and other places where Python 2 syntax is still welcome: Stackless, Pypy, Cython, Nuitka, MicroPython, Brython, etc... Python 2 hasn't gone anywhere.
Frankly, I think it's a damn shame IMHO that the Python 3 interpreter can't run Python 2 code! Not even with a command line switch. It should be able to switch syntax per module/file at least.
Anyway, to repeat, to me Python 3 is full of dubious toys for developers but has no compelling business value to drive adoption. It's cannibalizing the Python 2 community and ecosystem, but without that nobody would use it. It's not better than 2, just different.
If you were to start a new project and had to decide on a language, you would be better off (IMHO) with Rust or Go (or Python 2) than Python 3, generally speaking.
Let me turn the question on it's head: Python 3 adopters, can you give me a reason, a technical reason, why I should chose P3 over P2 for any project?
I'll throw out some things right off:
Performance. No. If you're using Python and worried about performance you've already committed stupidity and I'm not interested. Cython is your friend.
Async. No. I write Twisted code. Async has been done. Adding keywords to the language is stupid. (As an aside, I know Twisted is hard to use, and the docs sucked until recently, but it is a damn fine code base, written by really good and committed people, and it's an unsung under-appreciated treasure chest! Any Python networking code that does anything serious and doesn't use Twisted is probably doing too much work, poorly. The last thing the language needed was "async" as a keyword. "Foooooootguuuuuuun Jenkins!")
F-strings. No. More stupid and there are dozens of libs that do it.
Support? No. I can maintain the P2 code on my own if need be, but I don't need to because there are others, e.g. Tauthon, etc.. and I can support them. Plus as I said above, with no innovation comes no new bugs!
Type hints et. al. Ummm..., No. I was really stoked about this, but the first time I tried to use it (MyPy) I immediately broke it. I was doing things with the default keyword argument dict that just couldn't be represented in the type language. Valid useful Python code that the types can't handle is a thing. I like strong types, but Python has never benefited from over-nicety in typing. Quack, quack. Put another way, the coercive-type subset of Python is great but overly restrictive. (Which is not inherently bad, I think Elm-lang is brilliant!)
I love Python 2 because it has such a clean syntax, it deals sensibly with all the little fiddly bits that e.g. C makes you think about, and its semantics are powerful and flexible but elegant enough that you can hold the model (or a reasonable homologue) in your head.
From my POV Python 3 just messes up 2. I see no compelling technical reasons to use 3.
reply