piterpy
returns
on, and this fit the bill. My head hurts, and I've been down way too many rabbit holes. My takeaway is good and bad. On one hand, I see that you are trying to put some guard rails on a dangerously dynamic language. On the other hand, coding in this style in Python feels like hammering a square peg into a round hole. I haven't given up, but so far this is super difficult to debug. I was doing okay with mypy until I tried to perform composition. It's amazing it works given all the typing errors. I'd love any tips or pointers you might have on this (all the magic is in packt_downloader/init.py). I plan to do a proper write-up later on, but I would really like to figure out how to resolve the typing errors first. https://github.com/dgjustice/packtpub-downloader
Sounds like an interesting project @dgjustice, if I get some time I will take a look tomorrow!
I haven’t used the Returns library yet, although (I think) this is what is used in the Stories library as the ”monad” Success/Failure return object? I do really like that, in principle, as it forces you to enumerate all the error conditions of the use case. (In many projects I’ve worked on exception handling is an after thought.)
However, I do agree it does feel a bit awkward for me too atm. I’ve combined use case / Stories with a message bus driven architecture which currently doesn’t propagate the result (Success/Failure) object back to the Django view (in this case it would be easier to raise an exception). I think I just need to work on it as it probably is easily possible.
map
isn't working at the bottom of the script. I'm taking a wrapped function get_ip_addr
and map
ing it to a "pure" function (same as fmap, right?). This file is a very common pattern that I use, but I can't get mypy and returns to be happy. https://gist.github.com/dgjustice/257f7a2a2a8c67bc75bb1abcc8125f8f Thanks for any advise!
returns
library, unfortunately. You can ask questions in the issue tracker on GitHub. It's totally fine. We even have question label for this: https://github.com/dry-python/returns/issues?q=is%3Aissue+is%3Aopen+label%3Aquestion
These chat rooms left for historical purposes only. All active maintainers of the project have left gitter.
Projects are still properly maintained. If you have any questions, please file an issue in our issue tracker:
Issues are better to keep track of the community interests. It could be converted to tasks easily. It preserves the history of resolution. It's google friendly. Let's keep our conversation in a structured way! See you there.
alt
function in returns.Result
is.
map_failure