On Thu, Feb 10, 2022 at 8:57 AM David Mertz, Ph.D. <david.me...@gmail.com> wrote:
> Don't forget leap seconds! :-) > TAI only :-) -CHB On Thu, Feb 10, 2022, 11:45 AM Christopher Barker <python...@gmail.com> > wrote: > >> 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, Feb 10, 2022 at 7:48 AM Paul Moore <p.f.mo...@gmail.com> wrote: >> >>> On Thu, 10 Feb 2022 at 15:21, Aman Pandey <amanpandey5...@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-le...@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-le...@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/ >> > -- 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-le...@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/OBR4WFFDE52SAY3IMDHEBYAQLLSKYADN/ Code of Conduct: http://python.org/psf/codeofconduct/
