Retrying seems perfect for a library to me. For instance, Haskell has a popular retry library https://hackage.haskell.org/package/retry-0.8.1.0/docs/Contr... and I wouldn't consider it bad to just bring it in.
Is this more symptom of Python deps being "riskier" than Haskell deps due to types or versioning or something?
I just don’t find this tricky. If only every problem I need to solve is as simple as this one.
> Is this more symptom of Python deps being "riskier" than Haskell deps due to types or versioning or something?
No, it’s a distaste for tons of small third-party packages that could easily be done in place. If anything I found Haskell deps more prone to breakage with upgrades compared to Python deps (given my limited experience with Haskell), at least with the set of popular packages I tend to use. Part of that is Python packages tend to not depend on a ton of other packages.
I agree, it's harder to get right that it seems from first glance. The number of implementations I've seen with broken or not-honoured timeouts...
Python also had a retrying library; apparently it's no longer maintained. I've used the tenacity "fork", which has also evolved/introduced some great features like combinable and chainable wait/backoff.
No, I don’t have that notion. Apparently not every package on npm is small or trivial, but the abuse of trivial packages is most well-known and disastrous in the npm ecosystem.
Edit: My god, iOS autowrong is all the rage today.
What errors should be considered retryable, vs raise immediately?
Do you log a retryable error? I've had systems mysteriously "hung" before which on closer inspection were infinitely retrying with a retry library that didn't log anything...
And if you do exceed your max retries, which error do you raise? The first one? The last one? There's no guarentee they'll be the same. A completely different "TooManyRetries" error?
These are the concerns I'd like to see addressed in a high level overview of a library like this one.
"new" sounds like "neeuuuuu" in US English, and a diphtong "nuuu" in British English.
"nieuw" sounds like "niii" followed by a very short "oooo" as in "do" followed by a slightly more pronounced "w" at the end.
I'm aware that there are proper ways to codify pronunciation, but it's more fun this way and I know nothing of it.
Am I the only one that thinks that is a bit excessive?
If you accept '60s' as 60 seconds, then the next questions are:
- Will it also accept '60000ms'?
- What does it do if I pass an int or float anyway? Will it implicitly take it to be seconds?
- Will it throw an exception if I use an unexpected value? If so, which exceptions can I expect? Will it just chug along and use a default?
would be nice to have
Which uses the interesting approach of setting all "units" to random floats:
A complete set of independent base units (meters, kilograms, seconds, coulombs, kelvins) are defined as randomly-chosen positive floating-point numbers. All other units and constants are defined in terms of those. In a dimensionally-correct calculation, the units all cancel out, so the final answer is deterministic, not random. In a dimensionally-incorrect calculations, there will be random factors causing a randomly-varying final answer.
Which presumably is done to avoid overhead from carrying around units with each number, but forces you to run calculations multiple times (with different random seeds) to verify the result is correct.
I always wandered if that was a nod to Guido Van Rossum that people like naming python packages in Dutch?
I joked that we should name our library such that you would have to do
from driemaal import scheepsrecht
Although that way may not be obvious at first unless you're Dutch."
-- Tim Peters, The Zen of Python
(And you have an office in Utrecht! Cozy.)
So that's why you guys speak Dutch anyway!
a simple while True + try/catch + time.sleep(n*2) will do exponential backoff pretty easily.
seems to me that the authors wrote their own library instead of trying to make the ones that didn't meet their need better. well, they never mentioned they tried...
anyways, some of their choices like that long variable name are odd to me. i can understand the unit problem though. golang solves that so nicely!