Hacker News Reader

Comment by leetrout | Hacker News Reader

I don’t have a better solution but I was taken back by the length of the very verbose / descriptive param

retry_window_after_first_call_in_seconds

Am I the only one that thinks that is a bit excessive?

If you're using something like this, then the details of when, what and how you retry is probably something you care about, so having the library be explicit about it and making it possible to know what something means without having to look at the docs seems sensible to me.

This is some Java-level explicitness. Maybe, drop the `_seconds` suffix and replace it with something like `retry_window_after_first_call = '60s'`?

I agree it might look a bit excessive, but it greatly cuts down on complexity and possible unexpected behavior.

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?

Something I picked up from another developer is to use timedelta for these type of parameters. It avoids hoping that you get the right granularity for everyone.

   retry_window_after_first_call=timedelta(minutes=3.5)
   retry_window_after_first_call=timedelta(days=2)
   retry_window_after_first_call=timedelta(minutes=50)

Nice! Yes this is the better option. IMO, should just be

  retry_window=timedelta(...)

60s. was wondering how we could add physical units to python? highjack the number literals and variables like this: 1.s, pi.radians? or maybe the way golang does it: 1 * time.seconds?

would be nice to have

Sounds like a fun hack, I encourage you to give it a try and then never EVER use it in real code :P

There's this: https://pint.readthedocs.io/en/0.10.1/

I also found this package: https://github.com/sbyrnes321/numericalunits

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.

While the idea of '60s' is interesting, in lieu of that I always err on the side of explicitly specifying the time units when the argument provided is just a number. Not doing so has bitten me too many times.

yes it is excessive!

Reply on news.ycombinator.com