You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Datetime has many methods that "serializes" an instance to some other format - toordinal, timestamp, isoformat, etc. Most methods that "serialize" a datetime have a corresponding method that "deserializes" that method, or another way to reverse the operation:
strftime / strptime
timestamp / fromtimestamp
isoformat / fromisoformat
toordinal / fromordinal
timetuple / datetime(*thetuple[0:6])
However, as I found out when implementing dateutil.parser.isoparse, there is no simple way to invert isocalendar().
I have an implementation as part of dateutil.parser.isoparse:
I have a first-pass PR, a few questions to address:
Should it take three arguments or a single 3-tuple? (I've gone with 3 arguments)
Since all three arguments are required, should we make them positional-only?
Should we allow time components in the datetime flavor of this? If so, I think we would also want datetime.isocalendar() to return a longer tuple, which would be backwards incompatible.
Should we add a tz argument in the datetime flavor?
I think for questions 3 and 4 the answer is no, modelling after .toordinal/.fromordinal.
The attached PR is more or less fully ready, I think the correct answers to 1, 3 and 4 are that we should go with 3 separate arguments and we should not allow either time components or tz components, at least in this version.
In the future, I don't think it will be backwards incompatible to add in these features if they are desired (though I imagine they won't be terribly in demand, and it's pretty easy to work around).
The only real remaining question is number 2. Right now I am allowing keyword arguments, but the only real value I see in doing that is that PEP-570 (positional-only parameters) is not done yet and it's kind of annoying to implement "positional only parameters" in the pure Python version. If anyone feels strongly about this, let me know, otherwise I'll switch the implementation over to positional-only parameters.
Activity
pganssle commentedon Feb 15, 2019
Datetime has many methods that "serializes" an instance to some other format - toordinal, timestamp, isoformat, etc. Most methods that "serialize" a datetime have a corresponding method that "deserializes" that method, or another way to reverse the operation:
However, as I found out when implementing
dateutil.parser.isoparse, there is no simple way to invertisocalendar().I have an implementation as part of dateutil.parser.isoparse:
https://github.com/dateutil/dateutil/blob/master/dateutil/parser/isoparser.py#L297
If there are no objections, I'd like to add an implementation in CPython itself. Thinking the name should be
fromisocalendar.matrixise commentedon Feb 15, 2019
+1
eamanu commentedon Feb 15, 2019
+1
pganssle commentedon Feb 16, 2019
I have a first-pass PR, a few questions to address:
datetimeflavor of this? If so, I think we would also want datetime.isocalendar() to return a longer tuple, which would be backwards incompatible.tzargument in the datetime flavor?I think for questions 3 and 4 the answer is no, modelling after .toordinal/.fromordinal.
pganssle commentedon Feb 17, 2019
The attached PR is more or less fully ready, I think the correct answers to 1, 3 and 4 are that we should go with 3 separate arguments and we should not allow either time components or tz components, at least in this version.
In the future, I don't think it will be backwards incompatible to add in these features if they are desired (though I imagine they won't be terribly in demand, and it's pretty easy to work around).
The only real remaining question is number 2. Right now I am allowing keyword arguments, but the only real value I see in doing that is that PEP-570 (positional-only parameters) is not done yet and it's kind of annoying to implement "positional only parameters" in the pure Python version. If anyone feels strongly about this, let me know, otherwise I'll switch the implementation over to positional-only parameters.
vstinner commentedon Apr 29, 2019
New changeset 88c0937 by Victor Stinner (Paul Ganssle) in branch 'master':
bpo-36004: Add date.fromisocalendar (GH-11888)
88c0937
vstinner commentedon Apr 29, 2019
Thanks Paul, nice enhancement!