General comments:
It seems like the consensus is moving towards making sure there always is a
database available. If this means including it in the standard Python
distribution as well, or only on Windows, I don't know, opinions on that are
welcome.
The steps to look for a database would then change to:
1. The path specified, if not None.
2. The module for timezone "overrides".
3. The OS database.
4. The database included in Python.
We need to determine if a warning should be raised in case of 4 or not, as
well as the name for the override module. I think the word "override" here is
possibly unclear, I'd prefer something like "timezone-update" or similar.
I'm personally a bit sceptical to writing a special updater/installer just
for this. I don't want to have a special unique way to install this package.
As it comes to OS packages, Christian Heimes pointed out that most Windows
installations today has Java installed, and kept updated, and it has a
zoneinfo database. We could consider using that on Windows as well, although
it admittedly feels quite icky.
I haven't been able to find any other common locations for the
zoneinfo database on Windows.
Specific answers:
On Tue, Dec 11, 2012 at 4:39 PM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote:
> I wonder if there needs to be something here about how to port from
> pytz to the new timezone library.
It would be nice to have, but I don't think it's necessary to have in the PEP.
> 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?
> 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?
> 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.
On Tue, Dec 11, 2012 at 5:07 PM, Antoine Pitrou <solip...@pitrou.net> wrote:
>> The ``is_dst`` parameter can be ``True`` (default), ``False``, or
>> ``None``.
>>
> 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.
On Wed, Dec 12, 2012 at 3:50 AM, Barry Warsaw <ba...@python.org> wrote:
>> This is likely the hardest part of this PEP as this involves updating the
> Oops, something got cut off there.
Ah, yes, I was going to write that the difficult bit was updating the
_datetime.c module.
> Why add a new module instead of putting all this into the existing datetime
> module, either directly or as a submodule? Seems like the obvious place to
> put it instead of claiming another top-level module name.
pytz as it is consists of several modules, and a significant amount of code,
it didn't feel right to move all that into the datetime.py module. It also
didn't feel right to then not implement it in _datetime.c, but perhaps that's
just me being silly.
But a submodule could work.
> I'm bikeshedding, but can we find a better name than `db` for the second
> argument? Something that makes it obvious we're looking for file system path?
Absolutely. db_path?
> I'd really like to see a TimeZoneError base class from which all these new
> exceptions inherit.
That makes sense.
>>The ``timezonedata``-package
>>-----------------------------
>
> Just to be clear, this doesn't expose any new modules, right?
That's the intention, yes, although I haven't investigated ways of knowing if
it's installed or not yet, and exposing a module is the obvious way of doing
that. But I'm hoping there will be better ways, right?
> One other thing that the PEP should describe is what happens on a distro that
> has timezone data, but which you also pip install the PyPI tzdata package.
> Which one wins? Is there a way to control it, other than providing an
> explicit path? Is there a way to uninstall the PyPI package? Does the API
> need to provide a method which tells you where the database it is using by
> default lives?
The PyPI package wins, I'll clarify that bit. I'm think the data should end
up in site-packages somewhere, and that it should be installable and
uninstallable with pip/easy_install and by simply deleting it.
On Wed, Dec 12, 2012 at 4:14 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> That's a backwards compatibility risk, though - many applications are likely
> coping just fine with the slightly corrupted time values, but would fall
> over if an exception was raised instead. The default should probably be
> chosen so that the single argument form of these calls continues to behave
> the same in 3.4 as it does in 3.3, emitting a DeprecationWarning to say that
> the default behaviour is going to change in 3.5 (so the *actual* default
> would be sentinel value, in order to tell the difference between an explicit
> True being passed and relying on the default behaviour).
Although explicit is better than implicit, I think this is one case where
this doesn't apply. The cases where you really care which half past two you
meant, or the cases where you want an error when you specify 2012-03-25 02:30
in Europe/Stockholm is exceedingly rare. Most people would not know this can
happen, and therefore they would not handle the errors, but they would not
want the application to fail when it does happen. I think the default
therefore should be True or False.
_______________________________________________
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
