26
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 29 May 2025
26 points (81.0% liked)
technology
23791 readers
460 users here now
On the road to fully automated luxury gay space communism.
Spreading Linux propaganda since 2020
- Ways to run Microsoft/Adobe and more on Linux
- The Ultimate FOSS Guide For Android
- Great libre software on Windows
- Hey you, the lib still using Chrome. Read this post!
Rules:
- 1. Obviously abide by the sitewide code of conduct. Bigotry will be met with an immediate ban
- 2. This community is about technology. Offtopic is permitted as long as it is kept in the comment sections
- 3. Although this is not /c/libre, FOSS related posting is tolerated, and even welcome in the case of effort posts
- 4. We believe technology should be liberating. As such, avoid promoting proprietary and/or bourgeois technology
- 5. Explanatory posts to correct the potential mistakes a comrade made in a post of their own are allowed, as long as they remain respectful
- 6. No crypto (Bitcoin, NFT, etc.) speculation, unless it is purely informative and not too cringe
- 7. Absolutely no tech bro shit. If you have a good opinion of Silicon Valley billionaires please manifest yourself so we can ban you.
founded 4 years ago
MODERATORS
Python also allows you to override what operators do meaning I can write
And that's totally valid code. Don't think many other languages allow that, and translating that would be a mess.
It's technically operator overloading, the wacky thing that Python allows you to do, is overload operators for base types like
intwhich I'm not sure if other languages allow you to do for base types.That's what I meant, you can modify the behavior of code by directly over riding the operator implementation for base types. What it really reveals is that Python
intis not at all a Cintor really any otherint.Directly translating syntax without knowing that the Python type is so vastly different from say, the C type is a recipe for latent disaster.
This is true.
My favorite weird Cpython implementation detail is that -5 to 256 are pre-cached when the interpreter is initialized. So identity checks using those numbers return True, but return False for other numbers:
At least in newer versions of Python it screams at you for doing identity checks with integers
Yes, but that is a common optimization, caching primitive types and common values. I believe the JVM has that behavior, as well as a couple Ruby implementations (MRI, possibly YARV but it's been a while since I looked at Ruby implementations)
Yeah, cashing the 8 bit values means using integer flags is a lot faster. Implementation details like that are always a kicker. Especially when Python's syntax kinda makes you want to say "val is 1" since it's more "human readable" than "val == 1".
This is actually abused for True and False too which are a subclass of integer with Sentinel values equal to 0 and 1.
Since they're technically different objects, True is 1 is False, but int(True) is 1 is True. True == 1 is True though.
Basically every language with an interpreter will do stuff like this, but it's usually not super well documented behavior as it's considered implementation detail or private API stuff.
I have absolutely had issues with this. My editor configuration
python-moderaises an error about this via flake8 butruff~~doesn't~~ didn't raise an error about this (and I have enabled experimental settings) so my co-worker added code like this and it slipped through.Ruff now has a rule for it but I think I was a very early adopter where this hadn't been implemented yet.
https://docs.astral.sh/ruff/rules/is-literal/
Python ~~3.13~~ 3.8+ now spits out a warning to stdout when you do this, it was a big enough issue that they had to bake a warning into the CPython interpreter lol.
But because it's a big enough issue, it also means there's probably tons of examples online of people writing code this way and that'll be something you have to be actively watching for when using generated code.
The reasoning models would probably ping on some forum post about it, but because it's technically valid Python code, there's a good chance that it would see enough identity comparisons to integer literals to think it's okay.
The hard part of programming always ends up being the undocumented implementation details like that. Syntax is easy once you can understand the structure, but it so easy to write something that technically works and passes the tests that will eventually fail spectacularly and be hard to find.
100% agree with everything you've said. I think it really illustrates how Python has not really done a good job around memory management.
By which I mean, it has done it well enough where you don't have to think about memory management normally and that actually ends up hurting you because the identity operator explicitly is about checking if two references point to the same object and people forget that, and then some interpreter optimizations around small integers make it so the is operator and equality operator behave the same for small values and people get a wrong impression about the identity operator.
I have the same problem with Python's "pass by assignment" way of doing things where it's not explicit enough for my liking. Don't get me wrong, I understand what it is doing after 20 years using the language but I sort of appreciate C like languages where references vs values are more explicit with things like ponters.
Zig has been interesting to me, for this reason.
Haven't gotten into Zig, but it's on my list. I'm trying to get into Go and Rust now. Especially since I too have almost 20 years of using Python under my belt and hit those annoying "sometimes I just want to be explicit" moments.
That being said I will always come back to Python especially because I do now understand those pitfalls that can totally stump someone who's new to the language. The general syntax and elegance of generator expressions is addictive for small projects and quick tools. No boilerplate and a few comprehensions can do the work of a whole library (albeit quite a bit slower, but pretty frequently runtime is secondary to maintenance time).
I do like that type hinting is becoming the standard in Python though. I have absolutely abused the private apis for reading type hints in my code to get a sorta poor man's runtime type validation in mission critical (database) fuctions. I've used type hints with a decorator to build API endpoints as well. Hope that someday Python finally just commits and stops pretending to be lazy Rust and just allows you to opt into static typing.