Tentative PEP 495 edits

Tentative PEP 495 edits

[sasha, 2015-09-21 19:50:41]

My favorite review tool is a red ballpoint pen, but short of that Rietveld is as good as anything else (or better). https://codereview.appspot.com/263300043/diff/1/pep-0495.txt File pep-0495.txt (right): https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode129 pep-0495.txt:129: interpretation of ``fold=None``.) If the LGTM https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode176 pep-0495.txt:176: The ``datetime.now()`` method called without arguments will set OK https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode181 pep-0495.txt:181: (the stdlib's fixed-offset time zone implementation, I would prefer "``tzinfo`` implementation" over "time zone implementation." In general I try to use two word "time zone" spelling for the common (vague) notion of a time zone. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode191 pep-0495.txt:191: is a new feature, separate from the addition of ``fold``.)` The This is fine except for the trailing backtick, but maybe this be moved to the first sentence of the section. E.g. "A new feature is proposed to facilitate conversion from naive datetime instances to aware." https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode207 pep-0495.txt:207: .. comment Is this true? Yes, assuming a post-PEP tz. Maybe this caveat should be mentioned in the "implication" sentence above. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode237 pep-0495.txt:237: (This is because ``==`` disregards the value of fold -- see below.) OK https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode265 pep-0495.txt:265: ambiguous times.) Great! I was looking for a way to express this concisely. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode283 pep-0495.txt:283: are not using the ``fold`` attribute.) OK https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode290 pep-0495.txt:290: specification), ``isoformat()``, and ``timetuple()``. Thanks for fixing the grammar and punctuation. If you can think of a way to split this run-on sentence into two (or three!) it will be even better. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode312 pep-0495.txt:312: pickle payload; and in the first bit of the 1st byte of the Thanks. I was being lazy with this one. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode322 pep-0495.txt:322: .. comment Have we discussed whether this exception is desirable? I would have expected somehow that the fold bit would be ignored in earlier Python versions. Tim and I independently wrote at some point that an exception would be raised in earlier Pythons even though with the PEP description at the time an invalid instance with a negative hour would be produced. I don't think it is possible to hide fold in the pickle so that it is ignored by older Python, but I added a provision that fold is only written out when the latest pickle protocol is used. I don't think it is a big deal: there are many ways in which newer python can produce pickles that are not readable by the old one. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode340 pep-0495.txt:340: .. comment I wonder if this is the right choice. It helps the promose that pre-PEP implementations aren't affected (even if they inherit the stdlib fromutc()) but I'm curious if there aren't places where a post-PEP would end up having to copy the stdlib fromutc() and then figure out how to add the fold bit where otherwise they would have been happy with the stdlib version. (E.g. a simple local tz implementation like tzinfo-examples.py.) Tim and I went back and forth on this and each of us changed their positions to the opposite in the process. At the end of the day, we agreed that while a generic backward compatible implementation of fromutc() is possible, we don't want to complicate the existing code and slow down applications that don't care about fold-correctness. The benefit to post-PEP tzinfos would be minimal, because in all cases that we reviewed a custom implementation is both simpler and faster than a generic one. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode397 pep-0495.txt:397: If the ``utcoffset()``, ``tzname()`` or ``dst()`` method is called on a Thanks. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode493 pep-0495.txt:493: not have ambiguous times (such as UTC). OK https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode513 pep-0495.txt:513: for hashing and comparisons. If you need an aware intra-zone I would delete "and avoid violating the requirements for hashing and comparisons" from the above. The rule discussed here makes preserving the hash invariant harder, not easier. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode525 pep-0495.txt:525: operator differently for intra- and inter-zone operations. For Thanks. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode532 pep-0495.txt:532: and intra-zone datetime subtraction, which each have the mathematical Thanks. https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode536 pep-0495.txt:536: .. comment Was this possible in the pre-PEP world? Would be good to add an explicit example (even if it required a non-stdlib non-pytz timezone -- the naive local zone from the doc examples would probably do). I don't think "``s == t`` but ``s - u != t - u``" is possible with any sane pre-PEP tzinfos. (An insane tzinfo can be constructed by having utcoffset() depend on some internal state.) The point that I make here is that other paradoxes exist now such as ``(t - u) - (s - u) != t - s``. For the latter, it is trivial to construct an example. Do you think we should include one? https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode545 pep-0495.txt:545: exception. Whenever one or both of the operands in inter-zone comparison is Thanks.

[GvR, 2015-09-21 20:24:24]

I committed everything that was non-controversial and did the best I could without invoking another round of review for the rest. (It was a little painful because Alexander just committed a few other changes that affected some of my edits. Please double-check my merges.) I think it's now ready to accept. Any last wishes? On Mon, Sep 21, 2015 at 12:50 PM, <alexander.belopolsky@gmail.com> wrote: > My favorite review tool is a red ballpoint pen, but short of that > Rietveld is as good as anything else (or better). > > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt > File pep-0495.txt (right): > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode129 > pep-0495.txt:129: interpretation of ``fold=None``.) If the > LGTM > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode176 > pep-0495.txt:176: The ``datetime.now()`` method called without arguments > will set > OK > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode181 > pep-0495.txt:181: (the stdlib's fixed-offset time zone implementation, > I would prefer "``tzinfo`` implementation" over "time zone > implementation." In general I try to use two word "time zone" spelling > for the common (vague) notion of a time zone. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode191 > pep-0495.txt:191: is a new feature, separate from the addition of > ``fold``.)` The > This is fine except for the trailing backtick, but maybe this be moved > to the first sentence of the section. E.g. "A new feature is proposed > to facilitate conversion from naive datetime instances to aware." > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode207 > pep-0495.txt:207: .. comment Is this true? > Yes, assuming a post-PEP tz. Maybe this caveat should be mentioned in > the "implication" sentence above. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode237 > pep-0495.txt:237: (This is because ``==`` disregards the value of fold > -- see below.) > OK > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode265 > pep-0495.txt:265: ambiguous times.) > Great! I was looking for a way to express this concisely. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode283 > pep-0495.txt:283: are not using the ``fold`` attribute.) > OK > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode290 > pep-0495.txt:290: specification), ``isoformat()``, and ``timetuple()``. > Thanks for fixing the grammar and punctuation. If you can think of a > way to split this run-on sentence into two (or three!) it will be even > better. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode312 > pep-0495.txt:312: pickle payload; and in the first bit of the 1st byte > of the > Thanks. I was being lazy with this one. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode322 > pep-0495.txt:322: .. comment Have we discussed whether this exception is > desirable? I would have expected somehow that the fold bit would be > ignored in earlier Python versions. > Tim and I independently wrote at some point that an exception would be > raised in earlier Pythons even though with the PEP description at the > time an invalid instance with a negative hour would be produced. > > I don't think it is possible to hide fold in the pickle so that it is > ignored by older Python, but I added a provision that fold is only > written out when the latest pickle protocol is used. > > I don't think it is a big deal: there are many ways in which newer > python can produce pickles that are not readable by the old one. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode340 > pep-0495.txt:340: .. comment I wonder if this is the right choice. It > helps the promose that pre-PEP implementations aren't affected (even if > they inherit the stdlib fromutc()) but I'm curious if there aren't > places where a post-PEP would end up having to copy the stdlib fromutc() > and then figure out how to add the fold bit where otherwise they would > have been happy with the stdlib version. (E.g. a simple local tz > implementation like tzinfo-examples.py.) > Tim and I went back and forth on this and each of us changed their > positions to the opposite in the process. At the end of the day, we > agreed that while a generic backward compatible implementation of > fromutc() is possible, we don't want to complicate the existing code and > slow down applications that don't care about fold-correctness. > > The benefit to post-PEP tzinfos would be minimal, because in all cases > that we reviewed a custom implementation is both simpler and faster than > a generic one. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode397 > pep-0495.txt:397: If the ``utcoffset()``, ``tzname()`` or ``dst()`` > method is called on a > Thanks. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode493 > pep-0495.txt:493: not have ambiguous times (such as UTC). > OK > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode513 > pep-0495.txt:513: for hashing and comparisons. If you need an aware > intra-zone > I would delete "and avoid violating the requirements for hashing and > comparisons" from the above. The rule discussed here makes preserving > the hash invariant harder, not easier. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode525 > pep-0495.txt:525: operator differently for intra- and inter-zone > operations. For > Thanks. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode532 > pep-0495.txt:532: and intra-zone datetime subtraction, which each have > the mathematical > Thanks. > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode536 > pep-0495.txt:536: .. comment Was this possible in the pre-PEP world? > Would be good to add an explicit example (even if it required a > non-stdlib non-pytz timezone -- the naive local zone from the doc > examples would probably do). > I don't think "``s == t`` but ``s - u != t - u``" is possible with any > sane pre-PEP tzinfos. (An insane tzinfo can be constructed by having > utcoffset() depend on some internal state.) > > The point that I make here is that other paradoxes exist now such as > ``(t - u) - (s - u) != t - s``. For the latter, it is trivial to > construct an example. Do you think we should include one? > > https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode545 > pep-0495.txt:545: exception. Whenever one or both of the operands in > inter-zone comparison is > Thanks. > > https://codereview.appspot.com/263300043/ > -- --Guido van Rossum (python.org/~guido) 

[sasha, 2015-09-21 21:28:54]

On Mon, Sep 21, 2015 at 4:24 PM, Guido van Rossum <gvanrossum@gmail.com> wrote: > I committed everything that was non-controversial and did the best I could > without invoking another round of review for the rest. > Thanks. > (It was a little painful because Alexander just committed a few other > changes that affected some of my edits. Please double-check my merges.) > I applied your changed on Github and reviewed the resulting diff. Everything looks good. I also re-read the rendered version and found one case of missing backticks that I fixed. > > I think it's now ready to accept. Any last wishes? > s/Draft/Final/ at last? :-) PS: The description of the Ukrainian 1990 transition is wrong. I had a correct description in some early posts on the mailing list, but when I started writing the PEP, I took information from my Mac assuming it had a more accurate history. I later discovered that the opposite was true. The database I had on one of my Linux machines several months ago, was more up to date than that on the Mac. I am tempted to leave the incorrect description for others to discover. The history may change again by that time. :-) > > On Mon, Sep 21, 2015 at 12:50 PM, <alexander.belopolsky@gmail.com> wrote: > >> My favorite review tool is a red ballpoint pen, but short of that >> Rietveld is as good as anything else (or better). >> >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt >> File pep-0495.txt (right): >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode129 >> pep-0495.txt:129: interpretation of ``fold=None``.) If the >> LGTM >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode176 >> pep-0495.txt:176: The ``datetime.now()`` method called without arguments >> will set >> OK >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode181 >> pep-0495.txt:181: (the stdlib's fixed-offset time zone implementation, >> I would prefer "``tzinfo`` implementation" over "time zone >> implementation." In general I try to use two word "time zone" spelling >> for the common (vague) notion of a time zone. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode191 >> pep-0495.txt:191: is a new feature, separate from the addition of >> ``fold``.)` The >> This is fine except for the trailing backtick, but maybe this be moved >> to the first sentence of the section. E.g. "A new feature is proposed >> to facilitate conversion from naive datetime instances to aware." >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode207 >> pep-0495.txt:207: .. comment Is this true? >> Yes, assuming a post-PEP tz. Maybe this caveat should be mentioned in >> the "implication" sentence above. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode237 >> pep-0495.txt:237: (This is because ``==`` disregards the value of fold >> -- see below.) >> OK >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode265 >> pep-0495.txt:265: ambiguous times.) >> Great! I was looking for a way to express this concisely. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode283 >> pep-0495.txt:283: are not using the ``fold`` attribute.) >> OK >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode290 >> pep-0495.txt:290: specification), ``isoformat()``, and ``timetuple()``. >> Thanks for fixing the grammar and punctuation. If you can think of a >> way to split this run-on sentence into two (or three!) it will be even >> better. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode312 >> pep-0495.txt:312: pickle payload; and in the first bit of the 1st byte >> of the >> Thanks. I was being lazy with this one. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode322 >> pep-0495.txt:322: .. comment Have we discussed whether this exception is >> desirable? I would have expected somehow that the fold bit would be >> ignored in earlier Python versions. >> Tim and I independently wrote at some point that an exception would be >> raised in earlier Pythons even though with the PEP description at the >> time an invalid instance with a negative hour would be produced. >> >> I don't think it is possible to hide fold in the pickle so that it is >> ignored by older Python, but I added a provision that fold is only >> written out when the latest pickle protocol is used. >> >> I don't think it is a big deal: there are many ways in which newer >> python can produce pickles that are not readable by the old one. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode340 >> pep-0495.txt:340: .. comment I wonder if this is the right choice. It >> helps the promose that pre-PEP implementations aren't affected (even if >> they inherit the stdlib fromutc()) but I'm curious if there aren't >> places where a post-PEP would end up having to copy the stdlib fromutc() >> and then figure out how to add the fold bit where otherwise they would >> have been happy with the stdlib version. (E.g. a simple local tz >> implementation like tzinfo-examples.py.) >> Tim and I went back and forth on this and each of us changed their >> positions to the opposite in the process. At the end of the day, we >> agreed that while a generic backward compatible implementation of >> fromutc() is possible, we don't want to complicate the existing code and >> slow down applications that don't care about fold-correctness. >> >> The benefit to post-PEP tzinfos would be minimal, because in all cases >> that we reviewed a custom implementation is both simpler and faster than >> a generic one. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode397 >> pep-0495.txt:397: If the ``utcoffset()``, ``tzname()`` or ``dst()`` >> method is called on a >> Thanks. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode493 >> pep-0495.txt:493: not have ambiguous times (such as UTC). >> OK >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode513 >> pep-0495.txt:513: for hashing and comparisons. If you need an aware >> intra-zone >> I would delete "and avoid violating the requirements for hashing and >> comparisons" from the above. The rule discussed here makes preserving >> the hash invariant harder, not easier. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode525 >> pep-0495.txt:525: operator differently for intra- and inter-zone >> operations. For >> Thanks. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode532 >> pep-0495.txt:532: and intra-zone datetime subtraction, which each have >> the mathematical >> Thanks. >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode536 >> pep-0495.txt:536: .. comment Was this possible in the pre-PEP world? >> Would be good to add an explicit example (even if it required a >> non-stdlib non-pytz timezone -- the naive local zone from the doc >> examples would probably do). >> I don't think "``s == t`` but ``s - u != t - u``" is possible with any >> sane pre-PEP tzinfos. (An insane tzinfo can be constructed by having >> utcoffset() depend on some internal state.) >> >> The point that I make here is that other paradoxes exist now such as >> ``(t - u) - (s - u) != t - s``. For the latter, it is trivial to >> construct an example. Do you think we should include one? >> >> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode545 >> pep-0495.txt:545: exception. Whenever one or both of the operands in >> inter-zone comparison is >> Thanks. >> >> https://codereview.appspot.com/263300043/ >> > > > > -- > --Guido van Rossum (python.org/~guido) > 

[GvR, 2015-09-21 21:50:33]

Sounds good. I'll approve it in a minute. On Mon, Sep 21, 2015 at 2:28 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote: > > > On Mon, Sep 21, 2015 at 4:24 PM, Guido van Rossum <gvanrossum@gmail.com> > wrote: > >> I committed everything that was non-controversial and did the best I >> could without invoking another round of review for the rest. >> > > Thanks. > > >> (It was a little painful because Alexander just committed a few other >> changes that affected some of my edits. Please double-check my merges.) >> > > I applied your changed on Github and reviewed the resulting diff. > Everything looks good. > > I also re-read the rendered version and found one case of missing > backticks that I fixed. > > >> >> I think it's now ready to accept. Any last wishes? >> > > s/Draft/Final/ at last? :-) > > PS: The description of the Ukrainian 1990 transition is wrong. I had a > correct description in some early posts on the mailing list, but when I > started writing the PEP, I took information from my Mac assuming it had a > more accurate history. I later discovered that the opposite was true. The > database I had on one of my Linux machines several months ago, was more up > to date than that on the Mac. I am tempted to leave the incorrect > description for others to discover. The history may change again by that > time. :-) > > >> >> On Mon, Sep 21, 2015 at 12:50 PM, <alexander.belopolsky@gmail.com> wrote: >> >>> My favorite review tool is a red ballpoint pen, but short of that >>> Rietveld is as good as anything else (or better). >>> >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt >>> File pep-0495.txt (right): >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode129 >>> pep-0495.txt:129: interpretation of ``fold=None``.) If the >>> LGTM >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode176 >>> pep-0495.txt:176: The ``datetime.now()`` method called without arguments >>> will set >>> OK >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode181 >>> pep-0495.txt:181: (the stdlib's fixed-offset time zone implementation, >>> I would prefer "``tzinfo`` implementation" over "time zone >>> implementation." In general I try to use two word "time zone" spelling >>> for the common (vague) notion of a time zone. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode191 >>> pep-0495.txt:191: is a new feature, separate from the addition of >>> ``fold``.)` The >>> This is fine except for the trailing backtick, but maybe this be moved >>> to the first sentence of the section. E.g. "A new feature is proposed >>> to facilitate conversion from naive datetime instances to aware." >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode207 >>> pep-0495.txt:207: .. comment Is this true? >>> Yes, assuming a post-PEP tz. Maybe this caveat should be mentioned in >>> the "implication" sentence above. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode237 >>> pep-0495.txt:237: (This is because ``==`` disregards the value of fold >>> -- see below.) >>> OK >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode265 >>> pep-0495.txt:265: ambiguous times.) >>> Great! I was looking for a way to express this concisely. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode283 >>> pep-0495.txt:283: are not using the ``fold`` attribute.) >>> OK >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode290 >>> pep-0495.txt:290: specification), ``isoformat()``, and ``timetuple()``. >>> Thanks for fixing the grammar and punctuation. If you can think of a >>> way to split this run-on sentence into two (or three!) it will be even >>> better. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode312 >>> pep-0495.txt:312: pickle payload; and in the first bit of the 1st byte >>> of the >>> Thanks. I was being lazy with this one. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode322 >>> pep-0495.txt:322: .. comment Have we discussed whether this exception is >>> desirable? I would have expected somehow that the fold bit would be >>> ignored in earlier Python versions. >>> Tim and I independently wrote at some point that an exception would be >>> raised in earlier Pythons even though with the PEP description at the >>> time an invalid instance with a negative hour would be produced. >>> >>> I don't think it is possible to hide fold in the pickle so that it is >>> ignored by older Python, but I added a provision that fold is only >>> written out when the latest pickle protocol is used. >>> >>> I don't think it is a big deal: there are many ways in which newer >>> python can produce pickles that are not readable by the old one. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode340 >>> pep-0495.txt:340: .. comment I wonder if this is the right choice. It >>> helps the promose that pre-PEP implementations aren't affected (even if >>> they inherit the stdlib fromutc()) but I'm curious if there aren't >>> places where a post-PEP would end up having to copy the stdlib fromutc() >>> and then figure out how to add the fold bit where otherwise they would >>> have been happy with the stdlib version. (E.g. a simple local tz >>> implementation like tzinfo-examples.py.) >>> Tim and I went back and forth on this and each of us changed their >>> positions to the opposite in the process. At the end of the day, we >>> agreed that while a generic backward compatible implementation of >>> fromutc() is possible, we don't want to complicate the existing code and >>> slow down applications that don't care about fold-correctness. >>> >>> The benefit to post-PEP tzinfos would be minimal, because in all cases >>> that we reviewed a custom implementation is both simpler and faster than >>> a generic one. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode397 >>> pep-0495.txt:397: If the ``utcoffset()``, ``tzname()`` or ``dst()`` >>> method is called on a >>> Thanks. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode493 >>> pep-0495.txt:493: not have ambiguous times (such as UTC). >>> OK >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode513 >>> pep-0495.txt:513: for hashing and comparisons. If you need an aware >>> intra-zone >>> I would delete "and avoid violating the requirements for hashing and >>> comparisons" from the above. The rule discussed here makes preserving >>> the hash invariant harder, not easier. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode525 >>> pep-0495.txt:525: operator differently for intra- and inter-zone >>> operations. For >>> Thanks. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode532 >>> pep-0495.txt:532: and intra-zone datetime subtraction, which each have >>> the mathematical >>> Thanks. >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode536 >>> pep-0495.txt:536: .. comment Was this possible in the pre-PEP world? >>> Would be good to add an explicit example (even if it required a >>> non-stdlib non-pytz timezone -- the naive local zone from the doc >>> examples would probably do). >>> I don't think "``s == t`` but ``s - u != t - u``" is possible with any >>> sane pre-PEP tzinfos. (An insane tzinfo can be constructed by having >>> utcoffset() depend on some internal state.) >>> >>> The point that I make here is that other paradoxes exist now such as >>> ``(t - u) - (s - u) != t - s``. For the latter, it is trivial to >>> construct an example. Do you think we should include one? >>> >>> https://codereview.appspot.com/263300043/diff/1/pep-0495.txt#newcode545 >>> pep-0495.txt:545: exception. Whenever one or both of the operands in >>> inter-zone comparison is >>> Thanks. >>> >>> https://codereview.appspot.com/263300043/ >>> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> > > -- --Guido van Rossum (python.org/~guido)