3 ms·
Python also makes no distinction between safe and unsafe code. Now, "ctypes" is maybe enough of a marker, but it just illustrates how easy it is to create dangi
by kzrdude 4y ago
Python also makes no distinction between safe and unsafe code. Now, "ctypes" is maybe enough of a marker, but it just illustrates how easy it is to create danging pointers in Python just like in C, if desired.
import ctypes
ptr = ctypes.c_char_p(0x1234) # integer to pointer cast
ptr.value # deref dangling pointer
And similar operations are available through numpy and the buffer API, just a bit harder to jump into those, but once you do, the same kind of mistakes can happen.
- pjmlp 4y agoIn BASIC, a wrong POKE could also kill the machine and a reboot was required. The big difference is that most of these mistakes are opt-in, while in C every line of code is a possible source for problems.
- IshKebab 4y agoRight but his point was that they aren't explicitly opt-in. There's no `unsafe` keyword you have to use in Python before you are allowed to do unsafe things. It's just based on documentation essentially. Therefore there's not really any issue with having a Python API that you have to be a bit careful with to use safely - as long as it is documented and relatively obvious, it's no different to ctypes.
- pjmlp 4y agoI would assert that import ctypes is the opt-in somehow.
- DougBTX 4y agoYeah, that's a fair argument. You'd probably expect any public API exposed by functions in the module importing ctypes to provide a "safe" interface. The difference would be if any of that public API was unsafe, in Rust you could force the caller to use the unsafe keyword too (since unsafe functions can only be called in unsafe blocks), whereas in Python you'd rely on documentation.