Greetings, Some time ago, I proposed adding a `.fromisocalendar` alternate constructor to `datetime` (bpo-36004 <https://bugs.python.org/issue36004>), with a corresponding implementation (PR #11888 <https://github.com/python/cpython/pull/11888>). I advertised it on datetime-SIG some time ago but haven't seen much discussion there, so I'd like to bring it to python-dev's attention as we near the cut-off for new Python 3.8 features. Other than the fact that I've needed this functionality in the past, I also think a good general principle for the datetime module is that when a class (time, date, datetime) has a "serialization" method (.strftime, .timestamp, .isoformat, .isocalendar, etc), there should be a corresponding /deserialization/ method (.strptime, .fromtimestamp, .fromisoformat) that constructs a datetime from the output. Now that `fromisoformat` was introduced in Python 3.7, I think `isocalendar` is the only remaining method without an inverse. Do people agree with this principle? Should we add the `fromisocalendar` method? Thanks, Paul
I think it’s a good idea. On Sat, Apr 27, 2019 at 11:43 AM Paul Ganssle <paul@ganssle.io> wrote:
Greetings,
Some time ago, I proposed adding a `.fromisocalendar` alternate constructor to `datetime` (bpo-36004 <https://bugs.python.org/issue36004>), with a corresponding implementation (PR #11888 <https://github.com/python/cpython/pull/11888>). I advertised it on datetime-SIG some time ago but haven't seen much discussion there, so I'd like to bring it to python-dev's attention as we near the cut-off for new Python 3.8 features.
Other than the fact that I've needed this functionality in the past, I also think a good general principle for the datetime module is that when a class (time, date, datetime) has a "serialization" method (.strftime, .timestamp, .isoformat, .isocalendar, etc), there should be a corresponding *deserialization* method (.strptime, .fromtimestamp, .fromisoformat) that constructs a datetime from the output. Now that `fromisoformat` was introduced in Python 3.7, I think `isocalendar` is the only remaining method without an inverse. Do people agree with this principle? Should we add the `fromisocalendar` method?
Thanks, Paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido (mobile)
I reviewed and merged Paul's PR. I concur with Guido, the new constructor perfectly makes sense and is useful. About the implementation: date and time are crazy beasts. Extract of the code: if not 0 < week < 53: out_of_range = True if week == 53: # ISO years have 53 weeks in them on years starting with a # Thursday and leap years starting on a Wednesday first_weekday = _ymd2ord(year, 1, 1) % 7 if (first_weekday == 4 or (first_weekday == 3 and _is_leap(year))): out_of_range = False if out_of_range: raise ValueError(f"Invalid week: {week}") "ISO years have 53 weeks in them on years starting with a Thursday and leap years starting on a Wednesday" !?! Victor Le sam. 27 avr. 2019 à 22:37, Guido van Rossum <guido@python.org> a écrit :
I think it’s a good idea.
On Sat, Apr 27, 2019 at 11:43 AM Paul Ganssle <paul@ganssle.io> wrote:
Greetings,
Some time ago, I proposed adding a `.fromisocalendar` alternate constructor to `datetime` (bpo-36004), with a corresponding implementation (PR #11888). I advertised it on datetime-SIG some time ago but haven't seen much discussion there, so I'd like to bring it to python-dev's attention as we near the cut-off for new Python 3.8 features.
Other than the fact that I've needed this functionality in the past, I also think a good general principle for the datetime module is that when a class (time, date, datetime) has a "serialization" method (.strftime, .timestamp, .isoformat, .isocalendar, etc), there should be a corresponding deserialization method (.strptime, .fromtimestamp, .fromisoformat) that constructs a datetime from the output. Now that `fromisoformat` was introduced in Python 3.7, I think `isocalendar` is the only remaining method without an inverse. Do people agree with this principle? Should we add the `fromisocalendar` method?
Thanks, Paul
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido (mobile) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
-- Night gathers, and now my watch begins. It shall not end until my death.
On 29.04.2019 16:30, Victor Stinner wrote:
I reviewed and merged Paul's PR. I concur with Guido, the new constructor perfectly makes sense and is useful.
About the implementation: date and time are crazy beasts. Extract of the code:
if not 0 < week < 53: out_of_range = True
if week == 53: # ISO years have 53 weeks in them on years starting with a # Thursday and leap years starting on a Wednesday first_weekday = _ymd2ord(year, 1, 1) % 7 if (first_weekday == 4 or (first_weekday == 3 and _is_leap(year))): out_of_range = False
if out_of_range: raise ValueError(f"Invalid week: {week}")
"ISO years have 53 weeks in them on years starting with a Thursday and leap years starting on a Wednesday" !?! https://www.staff.science.uu.nl/~gent0113/calendar/isocalendar.htm , linked from https://docs.python.org/3/library/datetime.html?highlight=isocalendar#dateti... Victor
Le sam. 27 avr. 2019 à 22:37, Guido van Rossum <guido@python.org> a écrit :
I think it’s a good idea.
On Sat, Apr 27, 2019 at 11:43 AM Paul Ganssle <paul@ganssle.io> wrote:
Greetings,
Some time ago, I proposed adding a `.fromisocalendar` alternate constructor to `datetime` (bpo-36004), with a corresponding implementation (PR #11888). I advertised it on datetime-SIG some time ago but haven't seen much discussion there, so I'd like to bring it to python-dev's attention as we near the cut-off for new Python 3.8 features.
Other than the fact that I've needed this functionality in the past, I also think a good general principle for the datetime module is that when a class (time, date, datetime) has a "serialization" method (.strftime, .timestamp, .isoformat, .isocalendar, etc), there should be a corresponding deserialization method (.strptime, .fromtimestamp, .fromisoformat) that constructs a datetime from the output. Now that `fromisoformat` was introduced in Python 3.7, I think `isocalendar` is the only remaining method without an inverse. Do people agree with this principle? Should we add the `fromisocalendar` method?
Thanks, Paul
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido (mobile)
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
-- Regards, Ivan
participants (4)
-
Guido van Rossum -
Ivan Pozdeev -
Paul Ganssle -
Victor Stinner