undefined | Better HN

0 pointskortex4y ago0 comments

> Python does

And it's awful. I use EAFP locally (to avoid TOCTOU and the like) at low level interfaces but I don't let it bubble up out of a function scope, because it is a goto in all but name.

I've also been increasingly using the `result` library/data structure. It's incredibly liberating to return an error as an object you can compose into other functions, vs try/catch, which does not compose.

Yes I write python almost like rust, and it's great. Strong types, interfaces, immutable types. It looks nothing like "old school python" but also behaves nothing like it. Gone are the day of "oh it crashed again, fix one line and rerun".

Exceptions should be for exceptional circumstances, not errors.

Edit: I see this is controversial. What do you take objection to? Making your python look less dynamic and more like rust? Try it before you knock it. Python's my favorite language, but I do not agree that many of the common "pythonic" patterns are good at scale.

https://returns.readthedocs.io/en/latest/pages/result.html

0 comments

Karunamon4y ago

Maybe I'm just too inexperienced, but I don't see the point of this library.

The linked example shows a really basic sqlalchemy model lookup. What does spewing these new types all over my code get me that returning None or an empty dict/list doesn't without the overhead?

    def find_user(user_id: int) -> Optional[User]:
      user = User.objects.filter(id=user_id)
      if user.exists():
        return user[0]
      else:
        return None

Not only is this idiomatic, it conveys the same semantic meaning. I'm using an IDE, as is anyone else working in a large codebase. I'll be told at the point of invocation that find_user could return None and I need to possibly deal with that.

dragonwriter4y ago

> Not only is this idiomatic, it conveys the same semantic meaning

No, it doesn’t. For a single computation like this, that pattern is roughly equivalent to Maybe (which contains no information about the case where there is no success result besides that it is absent) rather than Result (which has error information, kind of like an exception, but in the normal return path.)

For a series of computations, the composability of both Maybe and Result means that they are semantically richer.

Karunamon4y ago

Couldn't I just return a tuple instead if I wanted to give the caller information on the nature of the success or failure?

Also, both Django and SQLAlchemy throw proper exceptions on bad queries or DB errors, which is probably the right thing to do in the average app using these libraries (the exception bubbles up, getting logged, returning the appropriate http error, etc).

I'm not crapping on this library, mind, I just can't find the use case that justifies it.

1 more reply

eru4y ago

I find, that the problem with exceptions in Python is not so much that it is a goto, but that they are a bit like dynamic scoping (vs static scoping of variables), so you can not reason about them statically.

An example: suppose you have a function that does some work with the filesystem, and also calls some user-supplied code. (Perhaps because the user can subclass something etc, or because you are getting a callback, the details don't matter.)

Naturally your function might have some idea how to handle its own filesystem trouble, but you have no clue how to handle any filesystem exceptions that come from user provided code.

It's rather awkward to get this exactly right.

j / k navigate · click thread line to collapse

0 pointskortex4y ago0 comments

> Python does

And it's awful. I use EAFP locally (to avoid TOCTOU and the like) at low level interfaces but I don't let it bubble up out of a function scope, because it is a goto in all but name.

Exceptions should be for exceptional circumstances, not errors.

https://returns.readthedocs.io/en/latest/pages/result.html

0 comments

Karunamon4y ago

Maybe I'm just too inexperienced, but I don't see the point of this library.

The linked example shows a really basic sqlalchemy model lookup. What does spewing these new types all over my code get me that returning None or an empty dict/list doesn't without the overhead?

    def find_user(user_id: int) -> Optional[User]:
      user = User.objects.filter(id=user_id)
      if user.exists():
        return user[0]
      else:
        return None

dragonwriter4y ago

> Not only is this idiomatic, it conveys the same semantic meaning

For a series of computations, the composability of both Maybe and Result means that they are semantically richer.

Karunamon4y ago

Couldn't I just return a tuple instead if I wanted to give the caller information on the nature of the success or failure?

I'm not crapping on this library, mind, I just can't find the use case that justifies it.

1 more reply

eru4y ago

Naturally your function might have some idea how to handle its own filesystem trouble, but you have no clue how to handle any filesystem exceptions that come from user provided code.

It's rather awkward to get this exactly right.

j / k navigate · click thread line to collapse