Live data from Hacker News

Python exceptions considered an anti-pattern

sobolevn.me

61–69 of 69 posts

Re: Python exceptions considered an anti-pattern

#61
post #30

Earlier quoted context omitted.

Often the language is chosen because it is the only option like JS for web, or it is the best option for the project. For example, you are doing physics and you need a general purpose language that is easy to write and handles gigantic numbers correctly so you pick Python.

>Often the language is chosen because it is the only option like JS for web, or it is the best option for the project. For example, you are doing physics and you need a general purpose language that is easy to write and handles gigantic numbers correctly so you pick Python. You could pick Julia, or R. A community could create their own tools. It's not like JS, which has an absolute monopoly and people were forced to…

[deleted]

Re: Python exceptions considered an anti-pattern

#64
post #30

Earlier quoted context omitted.

Often the language is chosen because it is the only option like JS for web, or it is the best option for the project. For example, you are doing physics and you need a general purpose language that is easy to write and handles gigantic numbers correctly so you pick Python.

>Often the language is chosen because it is the only option like JS for web, or it is the best option for the project. For example, you are doing physics and you need a general purpose language that is easy to write and handles gigantic numbers correctly so you pick Python. You could pick Julia, or R. A community could create their own tools. It's not like JS, which has an absolute monopoly and people were forced to…

JS interpreter, thanks to asm.js, can be used to run any language. Knock yourself out.

Of course you get to deal with a bit of FFI when calling built-in functionality of the browser.

Re: Python exceptions considered an anti-pattern

#65

Earlier quoted context omitted.

>Often the language is chosen because it is the only option like JS for web, or it is the best option for the project. For example, you are doing physics and you need a general purpose language that is easy to write and handles gigantic numbers correctly so you pick Python. You could pick Julia, or R. A community could create their own tools. It's not like JS, which has an absolute monopoly and people were forced to…

JS interpreter, thanks to asm.js, can be used to run any language. Knock yourself out. Of course you get to deal with a bit of FFI when calling built-in functionality of the browser.

Thanks to adapters, you can plug an american fridge in a french socket. I'll still buy the one made for the local electrical system.

Re: Python exceptions considered an anti-pattern

#66

Earlier quoted context omitted.

JS interpreter, thanks to asm.js, can be used to run any language. Knock yourself out. Of course you get to deal with a bit of FFI when calling built-in functionality of the browser.

Thanks to adapters, you can plug an american fridge in a french socket. I'll still buy the one made for the local electrical system.

So, you'd write in an inferior language when even web framework authors don't want to?

(See CoffeeScript, TypeScript, Elm, etc. Or Transcrypt if you want pythonic semantics.)

I understand this being a business requirement made by a business droid. Other than that, there is really no reason to be married to JavaScript.

Re: Python exceptions considered an anti-pattern

#67
post #18

Earlier quoted context omitted.

I was about to post something similar to this. In java you need to specify what your function can throw and if it tries to throw something that it has not specified as being able to throw, then your program won't compile.

Agreed, checked exceptions solve the same problem, but having separate control flow mechanism for certain kinds of data still seems subpar. Return values can solve the same problems and are more general.

Not if you cannot enforce them to be checked.

Re: Python exceptions considered an anti-pattern

#68
post #52

> So, the sad conclusion is: all problems must be resolved individually depending on a specific usage context. ...and that's a good thing. Recognising that specific usage contexts require specific recovery strategies is a key part of effective program design. Division by zero is an exception, yes. That's basic math. Getting to the point where one of your inputs is "bad" (zero in this case) shows that you have a probl…

Interesting fact of life: floating point returns NaN or Infinity for certain operations and it propagates. Real pain in the rear to debug. You cannot even reliably trap on it most of the time because there are no such options in the compilers.

Re: Python exceptions considered an anti-pattern

#69

It amazes me how enduring formulaic it is to single out some particular design tradeoff of a language, draw up some examples of expressing something where that tradeoff creates worse code, and then act like it's some mortal flaw in the language. Python chose untyped exceptions, period. How is this surprising, given that its basis is untyped parameters? If you don't like that, use Java with its checked exceptions. Or…

Exactly. Besides, I fail to see how exceptions are the problem in there. > Exceptions are hard to notice No. In Java they are easy to notice. In Python we have a dynamic language, so there is no safety net for that. It's a limit of the language that we chose, by design, with pros and cons. It's not exception related. > So, the sad conclusion is: all problems must be resolved individually depending on a specific usage…

> Python is not made for this.

Maybe, but there are ungodly big and crufty codebases in Python all around the world, and a lot of stuff depends on them. And it turns out that Python was never meant to be the thing that is being depended on. That's unfortunate. Hence the whole gradual typing (mypy) and other kinds of safety efforts.

You're not forced to use this. But it seems pretty useful, even for scripts.

Post reply on HN