←back to thread

317 points est | 1 comments | | HN request time: 0.243s | source
Show context
blindseer ◴[] No.17448804[source]
My biggest problem with this change (and dataclasses) is that it is not backward compatible (I know that a backport of dataclass is available, but it is only for Python 3.6). Can people tell me how they deal with this? Are you using features that are only available in the version of Python all your colleagues / users have access to? Are you using the latest version of Python and hoping your colleagues and users can upgrade to that version of Python?

One main reason in my opinion as to why Python 2.7 stuck around for so long was that everyone agreed that it was the last stable version of Python 2, and the devs could make Python 3 changes without worrying significantly about backward compatibility. I've been using Python3 since Python 3.3 but have had to write code that was Python 2 compatible for large code bases for about 5 years because I knew colleagues / users of my packages would not upgrade. This meant using a select subset of features in Python 3 that had been backported to a version of Python 2.7 that I knew I could get my colleagues / users to upgrade to. It has been great to watch the language evolve and Python 3 really gets a lot of things right, but adding breaking syntax features every minor release is extremely annoying. I have to have a mental checklist of all the different possible subsets of features I have access to given a minimum version of Python I want to support. I've spent the last couple of years in my professional career converting large Python 2 only code bases to Python 3.3+. But if someone wants to use async, I need to bump the minor version. If someone wants to use type hinting I have to bump the minor version. If someone wants to use f-strings I have to bump the minor version. If someone wants to use data classes I have to bump the minor version. It's nuts (to me anyway)!

This sounds rant-y but I genuinely want to know what other people are doing to mitigate this. I love Python! I have spent years advocating its merits. But thinking about large codebases in Python just worries me and the future doesn't look promising here. Are Python developers hoping that once 2020 arrives they'll have a stable Python release and work on Python 4. We'll have the Python 2/3 split all over again!

My personal opinion is that Python needs an officially maintained translator for the latest Python features back to older versions. My current favorite package is py-backwards [0] but it is rather unmaintained at the moment.

[0] - https://github.com/nvbn/py-backwards

replies(5): >>17448827 #>>17448911 #>>17449596 #>>17451139 #>>17452566 #
marcus_holmes ◴[] No.17448827[source]
A bit off-topic, but I'm really curious. Why do people not upgrade Python and stick with 2.7?
replies(9): >>17448838 #>>17448856 #>>17448859 #>>17448861 #>>17448875 #>>17449153 #>>17450668 #>>17450749 #>>17451572 #
carapace ◴[] No.17451572[source]
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.

replies(2): >>17451656 #>>17452705 #
rzimmerman ◴[] No.17451656[source]
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.

replies(1): >>17452144 #
1. carapace ◴[] No.17452144[source]
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.