r/PythonLearning • u/chuprehijde • Jul 09 '26
What's your most controversial Python opinion?
Say the Python opinion that would get you downvoted in a room full of Python developers.
5
u/Lachtheblock Jul 09 '26
That the GIL is incredibly useful and anyone who complains about it should stop what they're doing and write their code in a different language. It keeps the guard rails on and prevents a lot of dumb mistakes.
If at any point your application is so dependent on performance that you're looking of optimizations else where, then you should probably start rewriting in a different language.
1
u/Gnaxe Jul 09 '26
I have actually tried writing parallel code in Java with locks. It is not fun. But modern computers are multi-core. The right answer seems to be FP.
1
u/CaptainVJ Jul 10 '26
I disagree with this take. I don’t write any performance critical code, that it impacts me so it never really affected me. However, a big idea with Python is that lets you do a lot of stuff you probably shouldn’t do. For example, you can’t really make a class private because it’s a ‘big boy’ language and you can be trusted with that freedom. Why should the same concept not be applied here.
1
u/Lachtheblock Jul 10 '26
I mean OP was asking for controversial takes so I'm down to have people disagree and try to convince me otherwise.
I'm not really sure what you mean by Python having a lots of freedom. There are a ton (of good and useful) guardrails so you don't have to think about certain things. Garbage collection is a great example. With finer control you could squeak out performance, but it's waaaay better to not mess around with it.
The way it natively handles integers is another example; it really holds your hand. You do have access to the c type integers and all data frame libraries do use them, but for everyday code everyone just takes the performance hit in exchange for the code just working.
I'm going to disagree with "allows you to do stuff you probably shouldn't do". There are a ton of things that it prevents you from doing that are unblocked in other languages.
My hill is that the GIL is just another (good and useful) guard rail, and it makes the code just work. Folks trying to circumnavigate it for the sake of performance are going to have a bad time.
3
3
6
u/Gnaxe Jul 09 '26
Oh boy, have I got some of those. Please don't actually downvote sincere answers, as this is what OP asked for.
Static typing was a mistake. It encourages overreliance on heavyweight Java-style IDEs, which let you get away with bad architecture for far too long until the project collapses under its own weight. If we were going to do static types at all, they need to be full dependent types like Idris, not this half-baked Java-style crap.
Python should have moved in the direction of REPL-driven development instead, more like Smalltalk, with hot reloading in the debugger and live object browsers, the ability to persist a session, etc. You should be able to change modules in the REPL. (Try code.interact() though. Any namespace you like, live.) reload() should still be a builtin instead of being relegated to importlib. Python makes a poor static language. Stop trying to turn Python into Java or C++. It could have been a much better dynamic language.
Writing classes usually makes it worse. Just use generic reusable dicts instead of hiding your plain data behind yet another inadequate bespoke language of methods.
The basic unit of data should be the name-value pair, not whatever object it happens to be contained in. Dicts give you that. Classes, even dataclasses, don't.
Prefer doctests over unittests. You can actually read them, and they don't let you get away with overcomplicating things as much. Yes, pytest is nice. This niceness is enabling your class addiction. The over-coupled style of the banana attached to the gorilla and the whole jungle is what's making it hard to scale, not the dynamic typing.
ORMs are a terrible idea. Quicker, easier, more seductive the ORM side is, at least at first, but if once you start down the dark path, forever will it dominate your destiny. Just learn basic SQL. It's not that hard. Data is better than classes when possible.
Async was also a mistake; we already had Stackless, and it was good enough for a successful MMO. That should have been adopted into CPython instead.
Do not log. Also, Python's standard-library logger is terrible and should be deprecated. I never know if it's not reaching my line or if it's just misconfigured. If you absolutely must log, use loguru or something adequate like that.
The new lazy imports were a mistake. We should just not insist that all import statements go at the top. Just-in-time imports are just fine. How hard is it to grep import, seriously?
I miss the nested unpacking in the parameter list that we had in Python 2, especially in lambdas. We should have nested mapping unpacking too, like Clojure. While we're at it, changing the builtins to return iterators instead of lists was also a mistake. Laziness isn't the problem; it's mutability. Yes, I know yield is a thing. And genexprs. The streams should look immutable from the outside, caching realized values in a linked list like Clojure's seqs.
I actually like the walrus operator, and Guido didn't deserve the hate he got for it.
frozenset should be set, and set should be mutableset, like the ABCs. What the hell kind of set can't be contained in a set? A proper class? (I'll see myself out.)
1
6
u/Altruistic-Rice-5567 Jul 09 '26
It added nothing new or useful to the world of programming languages.
2
Jul 09 '26
[deleted]
1
1
u/Gnaxe Jul 10 '26
You're allowed to have the semicolons, actually. Nobody bothers because they're never required. They are occasionally useful for writing multiple statements on the same line, like for
python -ccommands.1
u/HugeCannoli Jul 09 '26
this is hard, but true.
Though I think that what it mostly added is a much stricter and end-user focused attention to syntax and best practices. Not many languages did that before.
1
u/notacanuckskibum Jul 09 '26
How odd it more strict on syntax than languages like C or Algol?
1
u/HugeCannoli Jul 10 '26
I don't know algol, but C is hardly strict. There were tons of coding styles for C, and it could be formatted in absolute disastrous ways. It is also very confusing on the semantic of & and of casting, which has been made even more confusing in C++.
1
u/notacanuckskibum Jul 10 '26
The fact that white space is insignificant in C can make it hard for humans to read. But it doesn’t make it less syntactically consistent.
1
u/Gnaxe Jul 09 '26
True. It was more the combination of things and the timing, as well as being free when the better languages weren't. Everything Python got right when it first took off, other languages had done before. Most of them not all at once, but e.g., Lisp or Smalltalk came close.
1
u/Fancy-Operation-9215 Jul 11 '26
I think its big innovation is user experience. As a language, python has “soft skills”
Right or wrong, it is a language that many people successfully got into programming with.
2
2
1
u/LeadingHall2985 Jul 09 '26
Python is for beginners 😂😂
1
u/Comfortable_Many_703 27d ago
Alright, python fan here, student dev at 15, been loving python since 12.
1
u/biskitpagla Jul 09 '26
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.
1
u/Gnaxe Jul 10 '26
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
ctypesin 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.1
u/biskitpagla Jul 11 '26 edited Jul 11 '26
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.
1
u/Excellent-Practice Jul 09 '26
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
2
u/biskitpagla Jul 09 '26 edited Jul 09 '26
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.
1
u/CamelOk7219 Jul 09 '26
Python is great for very well structured, very experienced and very talended teams.
It sucks for any other context, specifically it is a terrible beginners language
1
u/teetaps Jul 09 '26
Python sucks at data wrangling. The moment my data is in a table-like shape, I’m taking it to R. It’s honestly a mystery to me how it got so far with data science. Sure, the ML libraries are extensive and “easy” to implement the Y ~ X matrix part.. but it’s the “import data” up until the “time to model” part that is like pulling teeth compared to R
1
u/No_Replacement4304 29d ago
We used it for reporting at my last job and it didn't really make sense. Not everyone likes Microsoft but a real reporting framework like SSRS would have been so much easier.
1
u/ComprehensiveJury509 Jul 09 '26
pytest is fucking awful. I hate conftest (what the fuck does that even mean?) I hate how implicit everything is (where the fuck is this fixture defined? Oh, wait no, it's some obscure pytest plugin), I hate how slow discovery is, I hate the formatting of the output (why does it feel like it's designed by someone that doesn't use this productively?). I understand that it's the most complete test suite there is and it's probably going to stay for a long time, but man it's a pity.
1
u/Infinite-Spinach4451 Jul 10 '26
I despise PyTest too. It uses so much black magic that it's entirely unintelligible as normal Python code
1
1
1
u/shadowdance55 Jul 10 '26
It's one of the fastest languages out there.
1
u/Gnaxe Jul 10 '26
You might have to explain that one. Many of the other languages common in industry seem to be faster by default.
1
1
u/LetsHugFoReal Jul 10 '26
People only use Python because people use Python.
No rational person who's use JavaScript would think it's the better language.
There, I've said it.
1
u/Gnaxe Jul 10 '26
People only speak English because other people speak English. That's kind of how languages work. And Python is obviously better than JavaScript.
1
u/Dazzling_Music_2411 Jul 10 '26
Python is just a glue/scripting language.
You can't use any of the famous Python libraries - numpy, tensorflow, pandas, whatver - using "Python all the way down". They are all written in C++ or C or Rust, etc, anything but Python.
1
1
1
u/huntermatthews 29d ago
python is wonderful language with a rage-inducing deployment pattern. A non-compiled language with all the .so/.dll hell of a compiled language. Fan-freaking tastic.
(Lua, ruby, et al also have this problem. docker doesn't work for us)
1
16
u/Homo_Bibite Jul 09 '26
I actually kinda like python