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

Dirkjan Ochtman dirkjan at ochtman.nl
Wed Dec 12 17:21:52 CET 2012

On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro <regebro at gmail.com> wrote:
>> 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,
> 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?

That entirely depends on when you define to be "the start". It seems
to me the consensus on python-dev has been that packages primarily
evolve outside the stdlib; it seems a bit weird to then, at the time
of stdlib inclusion, start changing the API.

>> Why is it True by default? Do we have statistics showing that Python
>> gets more use in summer?
> Because for some reason both me and Stuart Bishop thought it should be, but
> at least in my case I don't have any actual good reason why. Checking with
> how pytz does this shows that pytz in fact defaults to False, so I think
> the default should be False.

Here, too, I think that sticking with pytz's default would be a good idea.



More information about the Python-Dev mailing list