Hi all, I’d like to propose support for infinite dates, datetimes and timedeltas. They're very useful when you need to model ranges with one or both ends unbounded (e.g. “forever starting from June 15th 2020”). Without first-class infinite values, you can use None, or you can use the `min` and `max` attributes of Python’s datetime types, or some other arbitrary large values. Using None means you need to implement a path for None, and a path for everything else, and your various infinite values are indistinguishable. Using max/min means comparisons just work, but calculations need special treatment and you’re fundamentally misrepresenting your meaning. Temporal infinities give the best of both worlds: infinite values that interoperate seamlessly with the built-in types and behave sensibly and predictably. They’re also supported by Postgres! Usage examples:
from temporal_infinities import * from datetime import * DATETIME_POS_INF - datetime(2020, 6, 15) TIMEDELTA_POS_INF DATETIME_NEG_INF < date(2020, 6, 15) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '<' not supported between instances of 'DatetimeInfinity' and 'datetime.date' DATE_NEG_INF < date(2020, 6, 15) True date(2020, 6, 15) + TIMEDELTA_POS_INF DATE_POS_INF TIMEDELTA_NEG_INF == TIMEDELTA_NEG_INF True
My implementation is at https://github.com/AlexHillAlexHill/temporal-infinities <https://github.com/AlexHill/temporal-infinities> and is designed to be as consistent with the behaviour of floating-point infinities as possible. The expected behaviour of the various types is captured in test_matrix.csv, which is used to produce test cases. Blank cells indicate that a TypeError should be raised. It's tested back to Python 3.4. Previous discussion: https://mail.python.org/pipermail/python-ideas/2015-January/031414.html Thanks for your time! Alex
I think I recall that discussion -- but don't recall how it ended. Did it just peter out? Anyway, +1 form me -- I've actually got my own implementation as well. So it certainly has a use case, and it's really better to have one version in the stdlib. I haven't had a chance to review your implementation, but if it looks like you're getting support, I'll be sure to do so. -CHB On Tue, Jun 16, 2020 at 5:45 AM Alexander Hill <alex@hill.net.au> wrote:
Hi all,
I’d like to propose support for infinite dates, datetimes and timedeltas. They're very useful when you need to model ranges with one or both ends unbounded (e.g. “forever starting from June 15th 2020”).
Without first-class infinite values, you can use None, or you can use the `min` and `max` attributes of Python’s datetime types, or some other arbitrary large values. Using None means you need to implement a path for None, and a path for everything else, and your various infinite values are indistinguishable. Using max/min means comparisons just work, but calculations need special treatment and you’re fundamentally misrepresenting your meaning.
Temporal infinities give the best of both worlds: infinite values that interoperate seamlessly with the built-in types and behave sensibly and predictably. They’re also supported by Postgres!
Usage examples:
from temporal_infinities import * from datetime import * DATETIME_POS_INF - datetime(2020, 6, 15) TIMEDELTA_POS_INF DATETIME_NEG_INF < date(2020, 6, 15) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '<' not supported between instances of 'DatetimeInfinity' and 'datetime.date' DATE_NEG_INF < date(2020, 6, 15) True date(2020, 6, 15) + TIMEDELTA_POS_INF DATE_POS_INF TIMEDELTA_NEG_INF == TIMEDELTA_NEG_INF True
My implementation is at https://github.com/AlexHillAlexHill/temporal-infinities <https://github.com/AlexHill/temporal-infinities> and is designed to be as consistent with the behaviour of floating-point infinities as possible. The expected behaviour of the various types is captured in test_matrix.csv, which is used to produce test cases. Blank cells indicate that a TypeError should be raised. It's tested back to Python 3.4.
Previous discussion: https://mail.python.org/pipermail/python-ideas/2015-January/031414.html
Thanks for your time!
Alex _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S4H553... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Yeah, looks like it had support in principle but just went quiet. I'd be ok with just having it as a third-party library, but the real value comes when your data layer supports it directly - psycopg2, ORMs, etc. That's far more likely to happen if it's built-in. Thanks for responding! Cheers, Alex On Wed, Jun 17, 2020 at 11:48 AM Christopher Barker <pythonchb@gmail.com> wrote:
I think I recall that discussion -- but don't recall how it ended. Did it just peter out?
Anyway, +1 form me -- I've actually got my own implementation as well. So it certainly has a use case, and it's really better to have one version in the stdlib.
I haven't had a chance to review your implementation, but if it looks like you're getting support, I'll be sure to do so.
-CHB
On Tue, Jun 16, 2020 at 5:45 AM Alexander Hill <alex@hill.net.au> wrote:
Hi all,
I’d like to propose support for infinite dates, datetimes and timedeltas. They're very useful when you need to model ranges with one or both ends unbounded (e.g. “forever starting from June 15th 2020”).
Without first-class infinite values, you can use None, or you can use the `min` and `max` attributes of Python’s datetime types, or some other arbitrary large values. Using None means you need to implement a path for None, and a path for everything else, and your various infinite values are indistinguishable. Using max/min means comparisons just work, but calculations need special treatment and you’re fundamentally misrepresenting your meaning.
Temporal infinities give the best of both worlds: infinite values that interoperate seamlessly with the built-in types and behave sensibly and predictably. They’re also supported by Postgres!
Usage examples:
from temporal_infinities import * from datetime import * DATETIME_POS_INF - datetime(2020, 6, 15) TIMEDELTA_POS_INF DATETIME_NEG_INF < date(2020, 6, 15) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: '<' not supported between instances of 'DatetimeInfinity' and 'datetime.date' DATE_NEG_INF < date(2020, 6, 15) True date(2020, 6, 15) + TIMEDELTA_POS_INF DATE_POS_INF TIMEDELTA_NEG_INF == TIMEDELTA_NEG_INF True
My implementation is at https://github.com/AlexHillAlexHill/temporal-infinities <https://github.com/AlexHill/temporal-infinities> and is designed to be as consistent with the behaviour of floating-point infinities as possible. The expected behaviour of the various types is captured in test_matrix.csv, which is used to produce test cases. Blank cells indicate that a TypeError should be raised. It's tested back to Python 3.4.
Previous discussion: https://mail.python.org/pipermail/python-ideas/2015-January/031414.html
Thanks for your time!
Alex _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S4H553... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Tue, Jun 16, 2020 at 06:54:49PM +0800, Alexander Hill wrote:
Hi all,
I’d like to propose support for infinite dates, datetimes and timedeltas.
Some languages (R comes to mind, if I recall correctly) also support a "Not A Date" special value. Boost includes a not-a-date-time value: https://www.boost.org/doc/libs/1_56_0/doc/html/date_time/doxy.html#header.bo... If you've ever seen a database use 9-9-99 to mean an invalid or non-existent date, you'll probably appreciate having a Not-A-Datetime value :-) -- Steven
16.06.20 13:54, Alexander Hill пише:
I’d like to propose support for infinite dates, datetimes and timedeltas. They're very useful when you need to model ranges with one or both ends unbounded (e.g. “forever starting from June 15th 2020”).
Without first-class infinite values, you can use None, or you can use the `min` and `max` attributes of Python’s datetime types, or some other arbitrary large values. Using None means you need to implement a path for None, and a path for everything else, and your various infinite values are indistinguishable. Using max/min means comparisons just work, but calculations need special treatment and you’re fundamentally misrepresenting your meaning.
Temporal infinities give the best of both worlds: infinite values that interoperate seamlessly with the built-in types and behave sensibly and predictably. They’re also supported by Postgres!
First we need to solve some problems. 1. Parsing dates with more than 4-digit year. Note that many external implementations do not support such data, so we need a way to restrict the data range when convert them to string representation. 2. String representations and parsing for negative data. 3. String representations and parsing for infinity data (positive and negative). 4. If datetime.min will be the negative infinity, then what will be the result of `datetime.now() - datetime.min`? Or `(datetime.now() - datetime.min) // timedelta(days=1)`?
1. Dates beyond year 9999 aren't a prerequisite for infinite types - I see that as a separate issue. The fact that we can't represent dates between 9999 and infinity doesn't make infinity less useful :) 2 & 3. Yeah, string representation is something that needs to be decided on - that's a big potential bikeshed. My preference at this stage would be for these to be called e.g. date.inf_future and date.inf_past, and the string representation to be the same. timedelta could simply have timedelta.infinity, and since it supports __neg__, -timedelta.infinity would work just fine. I'd like to hear other views though. 4. In my implementation, `datetime.now() - DATETIME_NEG_INF == TIMEDELTA_POS_INF`. I haven't implemented the division dunder methods yet, but by analogy to float, I would say that `TIMEDELTA_POS_INF / timedelta(days=1) == float("inf")` and `TIMEDELTA_POS_INF // timedelta(days=1)` raises TypeError (the latter returns nan in the case of float). Thanks, Alex On Wed, Jun 17, 2020 at 2:57 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
16.06.20 13:54, Alexander Hill пише:
I’d like to propose support for infinite dates, datetimes and timedeltas. They're very useful when you need to model ranges with one or both ends unbounded (e.g. “forever starting from June 15th 2020”).
Without first-class infinite values, you can use None, or you can use the `min` and `max` attributes of Python’s datetime types, or some other arbitrary large values. Using None means you need to implement a path for None, and a path for everything else, and your various infinite values are indistinguishable. Using max/min means comparisons just work, but calculations need special treatment and you’re fundamentally misrepresenting your meaning.
Temporal infinities give the best of both worlds: infinite values that interoperate seamlessly with the built-in types and behave sensibly and predictably. They’re also supported by Postgres!
First we need to solve some problems.
1. Parsing dates with more than 4-digit year. Note that many external implementations do not support such data, so we need a way to restrict the data range when convert them to string representation.
2. String representations and parsing for negative data.
3. String representations and parsing for infinity data (positive and negative).
4. If datetime.min will be the negative infinity, then what will be the result of `datetime.now() - datetime.min`? Or `(datetime.now() - datetime.min) // timedelta(days=1)`? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2GZ5BN... Code of Conduct: http://python.org/psf/codeofconduct/
I've just updated my implementation to support multiplication and division of TIMEDELTA_INF, mimicking the behaviour of timedelta and float("inf"). Cheers, Alex On Wed, Jun 17, 2020 at 8:26 PM Alexander Hill <alex@hill.net.au> wrote:
1. Dates beyond year 9999 aren't a prerequisite for infinite types - I see that as a separate issue. The fact that we can't represent dates between 9999 and infinity doesn't make infinity less useful :)
2 & 3. Yeah, string representation is something that needs to be decided on - that's a big potential bikeshed. My preference at this stage would be for these to be called e.g. date.inf_future and date.inf_past, and the string representation to be the same. timedelta could simply have timedelta.infinity, and since it supports __neg__, -timedelta.infinity would work just fine. I'd like to hear other views though.
4. In my implementation, `datetime.now() - DATETIME_NEG_INF == TIMEDELTA_POS_INF`. I haven't implemented the division dunder methods yet, but by analogy to float, I would say that `TIMEDELTA_POS_INF / timedelta(days=1) == float("inf")` and `TIMEDELTA_POS_INF // timedelta(days=1)` raises TypeError (the latter returns nan in the case of float).
Thanks, Alex
On Wed, Jun 17, 2020 at 2:57 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
16.06.20 13:54, Alexander Hill пише:
I’d like to propose support for infinite dates, datetimes and timedeltas. They're very useful when you need to model ranges with one or both ends unbounded (e.g. “forever starting from June 15th 2020”).
Without first-class infinite values, you can use None, or you can use the `min` and `max` attributes of Python’s datetime types, or some other arbitrary large values. Using None means you need to implement a path for None, and a path for everything else, and your various infinite values are indistinguishable. Using max/min means comparisons just work, but calculations need special treatment and you’re fundamentally misrepresenting your meaning.
Temporal infinities give the best of both worlds: infinite values that interoperate seamlessly with the built-in types and behave sensibly and predictably. They’re also supported by Postgres!
First we need to solve some problems.
1. Parsing dates with more than 4-digit year. Note that many external implementations do not support such data, so we need a way to restrict the data range when convert them to string representation.
2. String representations and parsing for negative data.
3. String representations and parsing for infinity data (positive and negative).
4. If datetime.min will be the negative infinity, then what will be the result of `datetime.now() - datetime.min`? Or `(datetime.now() - datetime.min) // timedelta(days=1)`? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2GZ5BN... Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Jun 16, 2020 at 11:55 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
First we need to solve some problems.
1. Parsing dates with more than 4-digit year. Note that many external implementations do not support such data, so we need a way to restrict the data range when convert them to string representation.
do we? I've always been disappointed that parsing was not really part of datetime, but now I see the advantage. the datetime type(s) are their own thing -- they do not need to be fully compatible with anything else. It would be nice if, e.g. ISO 8601 supported "infinite time", but AFAIK, it doesn't, which makes interoperability a pain, but that's the case regardless. That doesn't mean we don't need a way to stringify infinite time, but all we can do is look to see if there is a common format we can use, and if not, make one up. But this is an argument for having it in the stdlib -- at least it would be consistent within Python. 2. String representations and parsing for negative data. why? wouldn't the only extension be infinite time and negative infinite time? nothing else would need to change at all. (unless there is more than one "standard" we want to support. 3. String representations and parsing for infinity data (positive and
negative).
yup -- let the bike shedding begin! 4. If datetime.min will be the negative infinity, I think that is a "Bad Idea" -- the infinities need their own representation. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On 18/06/20 3:00 am, Christopher Barker wrote:
3. String representations and parsing for infinity data (positive and negative).
yup -- let the bike shedding begin!
My bikeshed suggestions: DISTANT_FUTURE and DISTANT_PAST for datetimes MUCH_LATER and MUCH_EARLIER for timedeltas -- Greg
participants (5)
-
Alexander Hill -
Christopher Barker -
Greg Ewing -
Serhiy Storchaka -
Steven D'Aprano