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)