3 ms·

> The common "don't use exceptions for control flow" is broken right off the bat with StopIteration. I just think error handling in Python is god awful, really.

> The common "don't use exceptions for control flow" is broken right off the bat with StopIteration. I just think error handling in Python is god awful, really. Python explicitly does not agree with this... The same for a lot of your other complaints. It sounds like you are trying to write some other language in Python. Similarly if someone in a team using Java tried writing Python in Java they would complain a lot and end up with ugly hard to work with Java.

staticassertion 7y ago
> Python explicitly does not agree with this... OK, I'm willing to contend that that is the case. It doesn't have much to do with my overall issue with error handling. > The same for a lot of your other complaints. It sounds like you are trying to write some other language in Python. Similarly if someone in a team using Java tried writing Python in Java they would complain a lot and end up with ugly hard to work with Java. This is a very loose criticism of my post, I don't know how to respond to this. I've written Python for years, I think I gave it due credit for what it's good at. I am not trying to write some other language with Python, I just think Python is not a very good language compared to others given a lot of fairly typical constraints.
- brylie 7y ago
  Writing programs that will never grow beyond 150LOC, or roughly what fits on a screen + one page down I've written Python for years, I think I gave it due credit for what it's good at. I'm not sure how fair this assessment is, considering the multitude of Python projects of considerable size and scope.
  - staticassertion 7y ago
    Why? Of course it's entirely possible to build programs of a larger size. I'm just saying that after a certain point you start hitting walls. There are tons of ways to hedge against this - leveraging mypy early on, spending more money (on eng, infra, ops, etc), architecting around the issues, diligence, etc. It would be very silly for me to say that you can't build large systems in Python, I've worked on plenty that are much larger myself. Saying a language is possibly the best for two important use cases (exploration, small programs) is quite a statement, in my opinion. I don't think I believe that there's a language that excels so well in, say, building web services.
tayo42 7y ago
> Python explicitly does not agree with this... Whats the convincing argument for defending this? Ive always heard its just the way python is. Through experience using exceptions for anything other then exceptional situations and errors seems messy.
- jimnotgym 7y ago
  I suppose that comes back to use cases. I am one of the 'getting things done crowd', rather than a computer scientist. A lot of my work had been in things like EDI, or similar integration code. Imagine you are working through a series of EDI files and trying to post them to a badly documented Rest(ish) API of some enterprise system. If the file is bad (for whatever reason) you need to log the exception and put the file in a bad directory. Pythons use of exceptions for control flow is perfect for this. If file doesn't load for whatever undocumented reason, revert back to log and handle the fallout. "Oh I see a pattern, this API doesn't like address lines over 40 characters, I will add a custom exception to make the logging clearer, and go and try and see if I can fix this upstream. If not I will have to write some validation" It is this dirty world of taking some other systems dirty data and posting it to some other systems dirty API that I find Python rules. I have never worked on a large application where I owned the data end-to-end. Maybe there are better choices than Python for that?
  - macleginn 7y ago
    My feelings exactly. I write a lot of kinda scientific code that is not really computational but takes one or more horribly messy datasets and combines them to do some analysis. I now routinely use exceptions to filter out bad/complex data-points to deal with later.
Animats 7y ago
Python's exception system isn't bad. It's way ahead of Java's or C++ exceptions. The gyrations people go through in Go or Rust to handle errors are far worse. The exception hierarchy lets you capture an exception further up the tree to subsume all the more detailed exceptions. (Although the new exception hierarchy in 3.x is worse than the old one. In 2.x, "EnvironmentError" was the parent of all exceptions which represented problems outside the program, including the HTTP errors.[1] That seems to have been lost in 3.x). I think StopIteration is being removed. That was a a bad idea.
- bakery2k 7y ago
  I haven't seen anything about `StopIteration` being removed? In fact, the Python developers recently doubled-down on the design by introducing `StopAsyncIteration`.
  - brylie 7y ago
    PEP 479 might be what GP was referring to: https://www.python.org/dev/peps/pep-0479/ https://www.python.org/dev/peps/pep-0479/ PEP 479 is specifically related to generators: > If a StopIteration is about to bubble out of a generator frame, it is replaced with RuntimeError, which causes the next() call (which invoked the generator) to fail, passing that exception out. From then on it's just like any old exception.

staticassertion 7y ago

> Python explicitly does not agree with this... OK, I'm willing to contend that that is the case. It doesn't have much to do with my overall issue with error handling. > The same for a lot of your other complaints. It sounds like you are trying to write some other language in Python. Similarly if someone in a team using Java tried writing Python in Java they would complain a lot and end up with ugly hard to work with Java. This is a very loose criticism of my post, I don't know how to respond to this. I've written Python for years, I think I gave it due credit for what it's good at. I am not trying to write some other language with Python, I just think Python is not a very good language compared to others given a lot of fairly typical constraints.

brylie 7y ago
Writing programs that will never grow beyond 150LOC, or roughly what fits on a screen + one page down I've written Python for years, I think I gave it due credit for what it's good at. I'm not sure how fair this assessment is, considering the multitude of Python projects of considerable size and scope.
- staticassertion 7y ago
  Why? Of course it's entirely possible to build programs of a larger size. I'm just saying that after a certain point you start hitting walls. There are tons of ways to hedge against this - leveraging mypy early on, spending more money (on eng, infra, ops, etc), architecting around the issues, diligence, etc. It would be very silly for me to say that you can't build large systems in Python, I've worked on plenty that are much larger myself. Saying a language is possibly the best for two important use cases (exploration, small programs) is quite a statement, in my opinion. I don't think I believe that there's a language that excels so well in, say, building web services.

tayo42 7y ago

> Python explicitly does not agree with this... Whats the convincing argument for defending this? Ive always heard its just the way python is. Through experience using exceptions for anything other then exceptional situations and errors seems messy.

jimnotgym 7y ago
I suppose that comes back to use cases. I am one of the 'getting things done crowd', rather than a computer scientist. A lot of my work had been in things like EDI, or similar integration code. Imagine you are working through a series of EDI files and trying to post them to a badly documented Rest(ish) API of some enterprise system. If the file is bad (for whatever reason) you need to log the exception and put the file in a bad directory. Pythons use of exceptions for control flow is perfect for this. If file doesn't load for whatever undocumented reason, revert back to log and handle the fallout. "Oh I see a pattern, this API doesn't like address lines over 40 characters, I will add a custom exception to make the logging clearer, and go and try and see if I can fix this upstream. If not I will have to write some validation" It is this dirty world of taking some other systems dirty data and posting it to some other systems dirty API that I find Python rules. I have never worked on a large application where I owned the data end-to-end. Maybe there are better choices than Python for that?
- macleginn 7y ago
  My feelings exactly. I write a lot of kinda scientific code that is not really computational but takes one or more horribly messy datasets and combines them to do some analysis. I now routinely use exceptions to filter out bad/complex data-points to deal with later.

Animats 7y ago

Python's exception system isn't bad. It's way ahead of Java's or C++ exceptions. The gyrations people go through in Go or Rust to handle errors are far worse. The exception hierarchy lets you capture an exception further up the tree to subsume all the more detailed exceptions. (Although the new exception hierarchy in 3.x is worse than the old one. In 2.x, "EnvironmentError" was the parent of all exceptions which represented problems outside the program, including the HTTP errors.[1] That seems to have been lost in 3.x). I think StopIteration is being removed. That was a a bad idea.

bakery2k 7y ago
I haven't seen anything about `StopIteration` being removed? In fact, the Python developers recently doubled-down on the design by introducing `StopAsyncIteration`.
- brylie 7y ago
  PEP 479 might be what GP was referring to: https://www.python.org/dev/peps/pep-0479/ https://www.python.org/dev/peps/pep-0479/ PEP 479 is specifically related to generators: > If a StopIteration is about to bubble out of a generator frame, it is replaced with RuntimeError, which causes the next() call (which invoked the generator) to fail, passing that exception out. From then on it's just like any old exception.