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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
