[Python-Dev] Draft PEP for time zone support.
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 get_timezone() 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 get_timezone() 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.get_timezone(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