On 08/25/2015 05:16 PM, Alexander Belopolsky wrote: > Here is an outline of a "Strict Invalid Time Checking" that might work: > the values of datetime.fold attribute will be restricted to 0 and 1, but > the datetime constructor will accept None as a possible value of the > fold argument. The datetime constructor that receives fold=None will > set self.fold both ways and call self.tzinfo.utcoffset(self) twice > before returning the constructed instance. If the values returned by > the two utcoffset() calls match - an instance with self.fold=0 will be > returned, if not - they will be compared and an appropriate error returned. > > This design seems workable, but immediately raises a question: shouldn't > datetime constructor get the strict=False argument instead of encoding > it in the third value of fold? > > And if we want to have datetime(..., strict=True), why not just have > strict_datetime(...) function in your toolkit or on PyPI? Not every > 8-line function need to be in the standard library. > > We can discuss this and other questions if someone decides to champion > a Strict Invalid Time Checking PEP after PEP 495 is in-place.
Works for me. You've convinced me that it's a subtle enough problem to deserve its own PEP. And since it would likely involve adding either a new argument to some methods/constructors, or a new (invalid under PEP 495) value to the disambiguation flag, there's no sense in which it needs to be done at the same time; PEP 495 won't restrict future options. Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/
