| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
bpo-24416: Apply code review bpo-24416: Apply code review bpo-24416: Update docstrings bpo-24416: Apply third's codereview bpo-24416: Revert to support pickle bpo-24416: Update misc/news bpo-24416: Update __new__ Change pickling behavior of isocalendar() objects In order to leave IsocalendarDate as a private class and to improve what backwards compatibility is offered for pickling the result of a datetime.isocalendar() call, add a __reduce__ method to the named tuples that reduces them to plain tuples. Also add a test to this effect. Rename IsoCalendarDate to _IsoCalendarDate bpo-24416: Update datetime.rst bpo-24416: Update unittest Revert "Rename IsoCalendarDate to _IsoCalendarDate" This reverts commit 448a2109dfde1558a082de78171d17580995a950. Revert "Change pickling behavior of isocalendar() objects" This reverts commit 104264121ea49795da87fc803a270bdda8fa21d2. bpo-24416: Add pickle test bpo-24416: Update C API to subclass tuple bpo-24416: Change pickling behavior of isocalendar() objects bpo-24416: Update __new__ bpo-24416: Update whatsnew bpo-24416: Apply vstinner's review
This is only constructed internally and doesn't use keyword arguments. The equivalent change in the argument clinic on the C side would require us to move the forward declaration of the type above the clinic import for whatever reason, so it seems preferable to hold off on that for now.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
{date, datetime}.isocalendar() now return a private custom named tuple object
IsoCalendarDate rather than a simple tuple.
In order to leave IsocalendarDate as a private class and to improve what
backwards compatibility is offered for pickling the result of a
datetime.isocalendar() call, add a __reduce__ method to the named tuples that
reduces them to plain tuples. (This is the part of this PR most likely to cause
problems — if it causes major issues, switching to a strucseq or equivalent
would be prudent).
The pure python implementation of IsoCalendarDate uses positional-only
arguments, since it is private and only constructed by position anyway; the
equivalent change in the argument clinic on the C side would require us to move
the forward declaration of the type above the clinic import for whatever
reason, so it seems preferable to hold off on that for now.
bpo-24416: https://bugs.python.org/issue24416
Original PR by Dong-hee Na with only minor alterations by Paul Ganssle.
Co-authored-by: Dong-hee Na <donghee.na92@gmail.com>
| Back | FazBrowse Home | New Git URL |
This is a repackaging of #15633, because the history there got into conflict with master and handling a bunch of rebase conflicts when rebasing and maintaining history was too much work. Instead, I've squashed #15633 and added my own modifications on top.
I think this is more or less ready to merge, and I'd like to see it in for beta 1 of Python 3.9.
I can't really recall why datetime.IsoCalendarDate was public in the C extension in the current version of #15633, and nothing seems to go wrong if I remove it from the module, so I've gone ahead and done that.
@corona10 Mind taking a look?
https://bugs.python.org/issue24416