[Datetime-SIG] Calendar vs timespan calculations...

Guido van Rossum guido at python.org
Fri Jul 31 18:02:01 CEST 2015


On Fri, Jul 31, 2015 at 5:15 AM, Chris Barker <chris.barker at noaa.gov> wrote:

> On Thu, Jul 30, 2015 at 6:09 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>
>> On 07/30/2015 06:04 PM, Tim Peters wrote:
>>
>> I like Alexander's new tzstrict (subclass of tzinfo) idea best so far.
>>>
>>
I like it too.


> hmm -- somehow the tz object really feels like the wrong place for it.
>
> If you don't like flags,
>

If we're talking about a *global* flag, yes, that's a horrid idea.


> why not a datetime subclass? -- is that any more ugly than another tzinfo
> subclass?
>

Most code creates datetime instances through its constructor. But most code
creates tzinfo instances through factory functions (usually in 3rd party
libraries, since the stdlib has no tz database). I'm guessing there are way
more places where datetime() is called than places where a tzinfo is
created. So yes, a datetime subclass is uglier.


> We should also think about how to handle the Period arithmetic case --
> would that be a special kind of tzinfo object? I would think not -- after
> all, you'd certainly need a different kind of timedelta object. It would be
> nice not to have too many new objects.
>

If needed, we could create as many alternative time-delta-ish classes as we
wanted, and through the magic of Python's binary operator overloading (in
particular __radd__ and __rsub__) we could have each time-delta-ish class
implement a different kind of arithmetic on vanilla datetime objects.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150731/ce2b47c8/attachment-0001.html>


More information about the Datetime-SIG mailing list