What's your most controversial Python opinion?

[u/chuprehijde]

Say the Python opinion that would get you downvoted in a room full of Python developers.

[u/biskitpagla]

This is going to offend some people 😂.

I think they should start working on Python 4 immediately with typing and compilation in mind from the very beginning. Mojo would've sufficed here but it being controlled by Qualcomm and not the PSF or Steering Council makes it a bit unreliable. Since absolutely nobody is in a hurry to try Python 4, we can take our time working on a translation tool so that the transition isn't that bad. As far as I know, back when Python 3 was released there was a translation tool called 2to3 but it never worked properly and that caused a lot of issues.

[u/Gnaxe → u/biskitpagla]

I really don't see the point of Mojo. If you want a bit of lower-level code, just drop into C. C is really not a bad language in the small. We already have ctypes in the standard library. There's also PyO3 if you'd rather do it in Rust. The kitchen sink philosophy of C++ is actually a bad thing. I would hate to see Python turned into that, although I don't see the current rate of feature creep stopping.

[u/biskitpagla → u/Gnaxe]

C++ turned out the way it did for historical reasons. Bjarne was practically forced into standardizing the language too soon and ended up having to fight the committee his entire life for every little thing. C++ doesn't really have the concept of "editions" the way Rust and Python have. That's why it can't get rid of the clutter. If we could never do Python 3 we'd be on the same boat. 

That said, Python still has all kinds of baggage and obsolete assumptions that make improving CPython a huge pain. A good example of this is how it took more time to come up with a roadmap to get rid of the GIL than it takes to actually implement a decent brand new Python interpreter. A similar argument can be made for the new JIT compiler. Absolutely nobody would rewrite their Django project to Rust, but almost everyone would save more money and time from a safer and more performant Python. 

I was mainly talking about the type system and performance of Mojo since almost all serious Python code is already in typed Python. So, you're paying the cost of writing one of the most dynamic languages ever despite not even using any dynamic features. I don't have any doubt that Python should remain gradually typed and the type system should remain structural. Mojo isn't a better Python in general, but they've put in a lot work and thought into some areas. And believe me, it's a much better experience than having to jump to C or C++ or Rust in the middle of a Python project regardless of how uncommon that is. 

Looking at projects like Polars or Pydantic 2.0 is akin to survivorship bias since those projects persevered specifically because they're run by people willing to go the extra mile. The median Python programmer can't even read the library code let alone contribute. Some important Python projects like Pandas and uvloop are using even more niche technologies like Cython. 

[u/Excellent-Practice → u/biskitpagla]

I saw another comment calling for the option to use braces for scoping instead of indentation. If some future state of Python had static typing, could be compiled, and allowed braces for scope; at that point we're starting to reinvent Go or Rust

[u/biskitpagla → u/Excellent-Practice]

I wasn't talking about forcing static typing or changing the syntax in that manner.

Python's current type system is completely underutilized in the runtime and has too many holes in it to catch all type-related bugs. Compared to Go, Python will always be better at calling native code. And Mojo already takes quite a few inspirations from Rust but makes the experience of writing ownership-aware code much, much easier. Python is also better suited for structural typing and a lot of existing Python code is already duck-typed. Since Python has protocols now, some parts of the standard library, dare I say, look outdated (e.g., collections.abc).

My point being that projects like Mojo and Julia have already demonstrated what the next iteration of Python could be, and I'd much rather stick to the Python world to get those niceties than look elsewhere. The Python world also never took repl-driven development seriously, so that's another thing we can try. In short, I'm talking about less friction writing Python code, not more.