[ijs] > But here you're talking about the backward compatibility > problem, not the infinite regress problem.
If a change causes an infinite regress in formerly working code, then it's a "backward compatibility" problem too. If you write code from the start with the change in mind, of course there's no _inherent_ "infinite regress problem". > I guess I'll have to try to implement it and find out > where the headaches are myself. Have fun ;-) > It's also worth noting that backward compatibility cuts both > ways: because Stuart Bishop has chosen to implement > timeline arithmetic, any stdlib inclusion of pytz will have to > support timeline arithmetic in some form in order to > maintain backward compatibility with the package itself. We _could_ include pytz exactly the way it is today, without changing anything (else) in Python or pytz. There are lots of ways to deal with this. We could also say, more like dateutil did, that Python finds the Olson database useful but wants _nothing_ to do with timeline arithmetic, not ever. Etc. In any case, there is no active PEP at the moment proposing to add any new timezone implementations to Python. One step at a time. > I see how PEP 495 makes it possible to convert datetimes correctly > in all cases, Whew! You may well be only the second person to grasp this - thanks :-) > but I don't see how it makes it possible to implement > time zones that will be pytz-compatible without continuing to require > the localize/normalize dance. Indeed it doesn't - nor does it preclude it. PEP 495 says nothing whatsoever about timeline arithmetic, or about any other feature of any external timezone library except to the extent it adds new requirements on their Python-specifed tzinfo methods (chiefly .utcoffset() and .fromutc()). If pytz plays along with 495, then there's a new baseline to start from. For example, the current (I think) ptyz docs say: """ Converting between timezones also needs special attention. We also need to use the ``normalize()`` method to ensure the conversion is correct. """ That dance "should" no longer be necessary. But I don't know - perhaps pytz will continue to need it anyway. That's up to Stuart, not to me. _______________________________________________ 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/
