Since a started this:-)
1) the complexities are exactly why this *might* be a candidate for the stdlib. Those are the things that someone is likely to get wrong, or not think of, when they write something quick themselves, and only lightly test.
2) it doesn’t have to be everything for everyone- it has to be many things for many (most) people.
3) DST is a nightmare, plain and simple. The datetime module was useful for years even before it gained the ability to deal with it at all.[*]
An educational thing to explore, in any case.
-CHB
[*] now that I think about it, I would probably only do this without DST — including DST would require a DST database, which the stdlib doesn’t include.
On Thu, 10 Feb 2022 at 15:21, Aman Pandey <amanpandey5319@gmail.com> wrote:
>
> Hello Stephen, I think you misunderstood it. we are not talking about modifying the existing built-in function range rather adding a new function in datetime module that will generate the date and time between two periods.
> if we add a function like that in the datetime module the code will be exactly like the one you gave.
> Christopher was mentioning that he visualizes that function in the datetime module as something similar in syntax and execution like the built-in range function.
>
> what do you think if we add some function like that in datetime module wouldn't it be helpful?
I think something like this might occasionally be helpful. However,
for simple examples, it's pretty easy to write your own, sufficiently
so that people would expect more of a stdlib version. And
understanding the edge cases, correctly handling them, and designing
an API which makes the function easy to use while still having the
power to cover everyone's use cases, is a *lot* harder. It's that part
of the problem that is receiving the pushback here.
To give a concrete example, consider a range with a start of 1:30am on
a particular day, and a step of 1 day. If the range extends over a DST
change, then there's one day in the range where either there are no
valid 1:30am times, or there are *two*, equally valid 1:30am times
(depending on whether the clock is "going forwards" or "going
backwards"). What should the stdlib function do in this case? How
should the function deal with the fact that people can legitimately
expect different behaviours (for some applications "raise an
exception" could be the only safe option, for others, "use the nearest
valid time" might be)? Having flags that pick between different
behaviours scales badly, and is typically not a good design.
For your own code, you can write the behaviour that works best for
you, and for your application. For the stdlib, the behaviour has to
address the needs of *everyone*.
My feeling is that the complexity of a "does the right thing for
everyone" stdlib implementation would outweigh any benefit gained from
not having to write your own short function, tailored to your
particular needs.
Paul
_______________________________________________
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/5BNPSKGEJ6WE2GBYO4FGG5NMXXRJHJ7S/
Code of Conduct: http://python.org/psf/codeofconduct/
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
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/YBSYFBVT4MEFSCS76UX2LSGJYU64O5ZK/
Code of Conduct: http://python.org/psf/codeofconduct/