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. Any feature can be abused, but I don't think we should be using bad designs and bad APIs to justify the feature in the first place. > 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! ;-) _______________________________________________ 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/X4OI6OANR7WGJG4EV2KRR4SMBJUPESQL/ Code of Conduct: http://python.org/psf/codeofconduct/
