5 ms·

My favourite unsafe one-liner: eval((lambda:0).code.replace(co_consts=())) This one is slightly cheat-y because it does modify the code object, just n

My favourite unsafe one-liner: eval((lambda:0).__code__.replace(co_consts=())) This one is slightly cheat-y because it does modify the code object, just not the bytecode itself. "Purer" unsafety issues are treated as bugs and patched, but that doesn't stop them from existing periodically. I don't have a specific example on-hand but I bet you can find some in here: https://github.com/search?q=repo%3Apython%2Fcpython+segmentation+fault&type=issues https://github.com/search?q=repo%3Apython%2Fcpython+segmenta... Edit: This one is a decent example (and hasn't been fixed for a long time) https://github.com/python/cpython/issues/74957 https://github.com/python/cpython/issues/74957

pansa2 2y ago
> "Purer" unsafety issues are treated as bugs and patched, but that doesn't stop them from existing periodically. Yeah, the same is true for Lua (search for "segfault" here: https://www.lua.org/bugs.html https://www.lua.org/bugs.html). The difference is that Lua tends to have far fewer bugs overall than Python, mostly because it's so much simpler.
bubaumba 2y ago
That was intentional. And intentionally quite a lot of safe thing can be broken.
- Retr0id 2y ago
  Whoever opened issue #74957 appeared to have encountered it accidentally. But my initial point was, if you're writing raw bytecode, you're much more likely to hit memory unsafety issues relative to normal Python code.