On Mon, Dec 6, 2021 at 1:48 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-12-05 at 20:30:53 +1100,
> Chris Angelico <ros...@gmail.com> wrote:
>
> > On Sun, Dec 5, 2021 at 5:41 PM <2qdxy4rzwzuui...@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:
> >
> > https://pyauth.github.io/pyotp/#time-based-otps
>
> 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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3H4ZZVXKFRIJ5BDLG6HLVYEXJ4NMYICV/
Code of Conduct: http://python.org/psf/codeofconduct/
