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

On Thu, Jul 30, 2015 at 6:09 PM, Ethan Furman <ethan@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)