On Mon, Dec 6, 2021 at 1:48 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
On 2021-12-05 at 20:30:53 +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Sun, Dec 5, 2021 at 5:41 PM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
Also FWIW, I still think that if you're doing (b) or (c), then you're *not* doing default values anymore, you're moving pieces of the logic or the design into the wrong place. One example of (b) goes something like this:
def write_to_log(event, time=>current_time()): actually_write_to_log(event, time)
Very very common use-case for that:
I agree. *Not* conflating timestamps and event IDs is a good thing! APIs and libraries like that are making my point: the very notion of "overriding the current time" is a bad one. The notion of "defaulting to the current time" might be okay, in some systems, until it isn't.
Time-based OTPs are using timestamps. That's what they do. Defaulting to the current time is *precisely* how most 2FA systems work. Being able to override the time is useful primarily for testing. So for the TOTP case, I would say that "timestamp=>time.time()" is the perfect way to spell it.
The vast majority of calls are going to leave the time parameter at the default. (The one I linked to has separate "at" and "now" functions, but combining them makes very good sense.)
I disagree. Combining/conflating the time an event occurred and the time it's actually logged doesn't make sense at all. Or maybe I've spent too much time rummaging through logs from concurrent and parallel systems.
Oh, wait, we're veering off topic, but you like you said, this is Python Ideas! ;-)
I don't know why you'd have something in a logger that lets you configure the time, but my guess would be that it's the same thing: you can unit-test the logger with consistent inputs. For instance: def format_log_line(event, time=>current_time(), host=>get_host()): return ... # shorthand, obv you'd be using a proper testing framework assert format_log_line({...}, time=1638717131, host="example") == "..." TBH, I think that defaulting to "event happened right now" is about as good a default as you'll ever get. In some situations you'll know when the event happened... but honestly, I'd rather know when the log line happened too. So if I have an event with an inbuilt timestamp, I'll incorporate that into the *body* of the log line, and still have the logger add its own timestamp. But maybe I've spent too much time rummaging through logs from buggy systems. ChrisA