RetroSearch Browse

Thu Dec 13 00:30:46 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-December/123142.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-December/123142.html below:

[Python-Dev] Draft PEP for time zone support.