[Python-Dev] Draft PEP for time zone support. (original) (raw)

Terry Reedy tjreedy at udel.edu
Thu Dec 13 00:30:46 CET 2012

On 12/12/2012 10:56 AM, Lennart Regebro wrote:

It seems like calling gettimezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception? That could very well be. What are others opinions on this?

ValueError. That is what it is. Nothing special here.

Why not keep a bit more of the pytz API to make porting easy? The renaming of the timezone() function to gettimezone() is indeed small,

And gratuitous, to me. I don't generally like 'get' prefixes anyway.

but changing pytz.timezone(foo) to timezone.timezone(foo) is really significantly easier than renaming it to timezone.gettimezone(foo).

If we keep all of the API intact you could do try: import pytz as timezone except ImportError: import timezone Which would make porting quicker, that's true, but do we really want to keep unecessary API's around forever? Isn't it better to minimize the noise from the start?

While the module that was the basis for the ipaddress module was released on PyPI and its api developed however it did, the API was worked over quite a bit before the addition of ipaddress. So I agree that the current api can be revised before being more-or-less frozen in the stdlib.

It also seems relatively painless to keep localize() and normalize() functions around for easy porting. Sure, but you then have two ways of doing the same thing, which I think we should avoid.

I agree that this is precisely the time to remove cruft (if indeed it is such).

-- Terry Jan Reedy

More information about the Python-Dev mailing list