[Alex] > What would you say for the following proposal: leave tzinfo.tzname() > signature as is, but add > > def name(self, dt=None): > return self.tzname(dt) > > to the base tzinfo class. Now `tzname()` is a hook for tzinfo implementers, > but name() is the higher level function for the users. (Note that I never > liked that datetime.tzname() and tzinfo.tzname() had the same method name, > so my proposal may reflect a personal bias.)
Only if PEP 495 adds an obviously needed tzifno.classify(self, dt) method so that ordinary users don't have to become implementation experts to answer questions about datetimes that aren't about implementation details ;-) Short of that, I think I'd be happier if we changed tzinfo.tzname's signature to `dt=None`. No existing code would be harmed. New code would have to realize that any exploitation of the relaxed requirement could fail if an older tzinfo object is used. Same as that new code would have to realize that any exploitation of a new tzinfo.name() method could fail if an older tzinfo object is used. That's what "Version changed in" notes are for. I don't much care because I can't believe anyone uses a mix of tzinfos obtained from dozens of suppliers. BTW, this would be another use for starting to require that a tzinfo reveal a "version number" (however it's spelled). PEP 495 is a good place to start that too: any time Python changes tzinfo semantics, Python is creating _potential_ problems for everyone. PEP 495 is the first time we're proposing to change anything. _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
