4 ms·
No thanks. Here's why I dislike it. There's a lot of libraries out there in Python that appear to be DSLs or have custom syntaxes that heavily use decorators e
by iknownothow 3y ago
No thanks.
Here's why I dislike it. There's a lot of libraries out there in Python that appear to be DSLs or have custom syntaxes that heavily use decorators etc e.g. Flask or FastAPI. In exchange for learning these custom syntaxes they offer tangible value in terms of eliminating boilerplate or solving a particular use case really well. In case of Flask or FastAPI, they make writing http/rest servers a piece of cake.
This library however offers not much benefit over the following example from Effective Python and in return I have to learn a whole new Python.
def add_ints(a, b) -> Tuple[str, bool]:
if isinstance(a, int) and isinstance(b, int):
return a + b, True
else:
return None, False
result, status = add_ints(1, 1)
Basically it's is a lot of syntactic noise for very little.
- bb88 3y agoI don't even like that, since raising TypeError("args are not integers") would be easily more appropriate here, and arguably more pythonic.
- thebigspacefuck 3y agoIn your example it should be def add_ints(a: int, b: int) -> Tuple[int | None, bool]. I’m not a fan of the Tuple return type. This is how golang does things and while it works there I don’t like seeing this in Python code because the Tuple tells you nothing unless you follow this convention and you have to add the Tuple annotation on top of every return type making it harder to read. I don’t see a need for it here since you’re already returning an Optional[int] (int | None in Python 3.10+). You could also raise a TypeError. Also your type checker should catch this if a or b are not an int, so you might feel safe returning a+b at this point and having the return type be simply int.