7 ms·

Thanks for the clarifications. Indeed this is what I meant. Undefined behavior in particular isn't unavoidable, though the existence of meaningless statements o

Thanks for the clarifications. Indeed this is what I meant. Undefined behavior in particular isn't unavoidable, though the existence of meaningless statements often is. Python's philosophy of giving well-defined behavior to meaningless code seems wasteful. If your code is unintentionally executing sqrt(-1) (or unintentionally indexing out of bounds, etc) then something is wrong with your program. You don't necessarily need the behavior to be defined if there is a bug in your program. In the case that you want something predictable to happen, better to just abort(). Catching ValueError/IndexError in those cases is futile, how can one trust a buggy program to handle itself? Python using exceptions to signal both runtime errors and programmer errors is a design smell. The former should always be caught and handled, the latter should never be caught and should probably only reasonably abort().

geofft 9y ago
> If your code is unintentionally executing sqrt(-1) (or unintentionally indexing out of bounds, etc) then something is wrong with your program. This is not Python's design. You might dislike Python's design, sure (many people do!), but it is recommended Python practice to try to do something, catch the well-defined exception, and implement the fallback rather than to check in advance. https://docs.python.org/3.5/glossary.html#term-eafp https://docs.python.org/3.5/glossary.html#term-eafp https://blogs.msdn.microsoft.com/pythonengineering/2016/06/29/idiomatic-python-eafp-versus-lbyl/ https://blogs.msdn.microsoft.com/pythonengineering/2016/06/2... > Catching ValueError/IndexError in those cases is futile, how can one trust a buggy program to handle itself? The program is not buggy. (Also, it's absolutely possible to design software where bugs are contained to part of the code: for instance, if you hit a bug in your Python code while handling a web request, you should return a 500 to that user and carry on instead of aborting the whole web server. In fact, it is precisely the relative lack of undefined behavior in Python that makes this a good approach: if you were doing this in C, a wild pointer could well corrupt some other server thread!)
- first_amendment 9y ago
  I said unintentionally. Intentionally running code that may throw an exception and catching it predictably (in the normal EAFP fashion, which I am well aware of) doesn't apply to my argument. I'm arguing that an unintentional or unexpected ValueError, IndexError, TypeError, etc. means your program is buggy and there is no sane/practical way to 100% safely recover from it outside of restarting the process. Your example of the catch-all handler in a modular HTTP server is inappropriate and dangerous. Continuing to run a server with persistent in-process state after an unexpected exception risks corrupting data. Just because Python doesn't have C pointers doesn't mean it can't have inconsistent or incorrect state that can affect other server threads.
fulafel 9y ago
Just about all programs have bugs. There's a huge difference trying to defend against any possibility of undefined behaviour happening, because it may result in very bad unpredictable things happening to your computer, and defending against bugs that may result in the error getting signaled in a well defined way. This is the fundamental difference that makes C/C++ unsafe programming languages. (Yeah, this specific case of the exported add funciton is unlikely to be too apocalyptic, but the general guarantees are important).
- first_amendment 9y ago
  Rust, Python and other so-called safe languages are unsafe in the same fundamental ways C/C++ are unsafe. Safety is a larger class than "memory safety" which is what you are referring to. As long as the language permits running despite the existence of a bug / programming error, it is unsafe. RAM may not be corrupted, but state can nonetheless be left inconsistent and cause undesirable behavior ("unsafe" behavior).
  - junke 9y ago
    You are speaking as if it was an All-or-Nothing situation. > RAM may not be corrupted, but state can nonetheless be left inconsistent ... yes, but at least RAM is not corrupted, that's a little step towards reliability. And if you can manage your state in a transactional way, that's another step. Do you restart your OS when your program crashes?
    - first_amendment 9y ago
      I never said it was an all or nothing. My point is that trying to handle unexpected errors due to programming error is not safe and Python allows that. It doesn't matter if throwing ValueError exceptions on sqrt(-1) is well-defined, continuing to run the program by ignoring the exception is no less harmful than silent integer overflows or buffer overruns. I don't restart my OS when a process crashes because it has been designed to use hardware mechanisms to clean up dead processes. I absolutely do restart my OS when it kernel panics, it doesn't try:except:log:continue.
junke 9y ago
> Python's philosophy of giving well-defined behavior to meaningless code seems wasteful. The code has a well-defined meaning, it's just that the input domain is larger than the one defined in C.

geofft 9y ago

> If your code is unintentionally executing sqrt(-1) (or unintentionally indexing out of bounds, etc) then something is wrong with your program. This is not Python's design. You might dislike Python's design, sure (many people do!), but it is recommended Python practice to try to do something, catch the well-defined exception, and implement the fallback rather than to check in advance. https://docs.python.org/3.5/glossary.html#term-eafp https://docs.python.org/3.5/glossary.html#term-eafp https://blogs.msdn.microsoft.com/pythonengineering/2016/06/29/idiomatic-python-eafp-versus-lbyl/ https://blogs.msdn.microsoft.com/pythonengineering/2016/06/2... > Catching ValueError/IndexError in those cases is futile, how can one trust a buggy program to handle itself? The program is not buggy. (Also, it's absolutely possible to design software where bugs are contained to part of the code: for instance, if you hit a bug in your Python code while handling a web request, you should return a 500 to that user and carry on instead of aborting the whole web server. In fact, it is precisely the relative lack of undefined behavior in Python that makes this a good approach: if you were doing this in C, a wild pointer could well corrupt some other server thread!)

first_amendment 9y ago
I said unintentionally. Intentionally running code that may throw an exception and catching it predictably (in the normal EAFP fashion, which I am well aware of) doesn't apply to my argument. I'm arguing that an unintentional or unexpected ValueError, IndexError, TypeError, etc. means your program is buggy and there is no sane/practical way to 100% safely recover from it outside of restarting the process. Your example of the catch-all handler in a modular HTTP server is inappropriate and dangerous. Continuing to run a server with persistent in-process state after an unexpected exception risks corrupting data. Just because Python doesn't have C pointers doesn't mean it can't have inconsistent or incorrect state that can affect other server threads.

fulafel 9y ago

Just about all programs have bugs. There's a huge difference trying to defend against any possibility of undefined behaviour happening, because it may result in very bad unpredictable things happening to your computer, and defending against bugs that may result in the error getting signaled in a well defined way. This is the fundamental difference that makes C/C++ unsafe programming languages. (Yeah, this specific case of the exported add funciton is unlikely to be too apocalyptic, but the general guarantees are important).

first_amendment 9y ago
Rust, Python and other so-called safe languages are unsafe in the same fundamental ways C/C++ are unsafe. Safety is a larger class than "memory safety" which is what you are referring to. As long as the language permits running despite the existence of a bug / programming error, it is unsafe. RAM may not be corrupted, but state can nonetheless be left inconsistent and cause undesirable behavior ("unsafe" behavior).
- junke 9y ago
  You are speaking as if it was an All-or-Nothing situation. > RAM may not be corrupted, but state can nonetheless be left inconsistent ... yes, but at least RAM is not corrupted, that's a little step towards reliability. And if you can manage your state in a transactional way, that's another step. Do you restart your OS when your program crashes?
  - first_amendment 9y ago
    I never said it was an all or nothing. My point is that trying to handle unexpected errors due to programming error is not safe and Python allows that. It doesn't matter if throwing ValueError exceptions on sqrt(-1) is well-defined, continuing to run the program by ignoring the exception is no less harmful than silent integer overflows or buffer overruns. I don't restart my OS when a process crashes because it has been designed to use hardware mechanisms to clean up dead processes. I absolutely do restart my OS when it kernel panics, it doesn't try:except:log:continue.

junke 9y ago

> Python's philosophy of giving well-defined behavior to meaningless code seems wasteful. The code has a well-defined meaning, it's just that the input domain is larger than the one defined in C.