[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-12-21 - 2012-12-28) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3834 (-10) closed 24745 (+68) total 28579 (+58) Open issues with patches: 1678 Issues opened (32) == #9856: Change object.__format__(s) where s is non-empty to a TypeErro http://bugs.python.org/issue9856 reopened by eric.smith #16747: Remove 'file' type reference from 'iterable' glossary entry http://bugs.python.org/issue16747 opened by zach.ware #16748: Ensure test discovery doesn't break for modules testing C and http://bugs.python.org/issue16748 opened by zach.ware #16749: Fatal Python Error http://bugs.python.org/issue16749 opened by DaVinci #16754: Incorrect shared library extension on linux http://bugs.python.org/issue16754 opened by smani #16755: Distutils2 incorrectly works with unicode package names http://bugs.python.org/issue16755 opened by hotsyk #16757: Faster _PyUnicode_FindMaxChar() http://bugs.python.org/issue16757 opened by serhiy.storchaka #16758: SubprocessStartupError http://bugs.python.org/issue16758 opened by LtCdr(ret)nazrinasir #16761: Fix int(base=X) http://bugs.python.org/issue16761 opened by serhiy.storchaka #16762: test_subprocess failure on OpenBSD/NetBSD buildbots http://bugs.python.org/issue16762 opened by neologix #16763: test_ssl with connect_ex don't handle unreachable server corre http://bugs.python.org/issue16763 opened by neologix #16764: Make zlib accept keyword-arguments http://bugs.python.org/issue16764 opened by ebfe #16767: Cannot install Python 2.7 in Wine 1.4.1 http://bugs.python.org/issue16767 opened by Joe.Borg #16769: Remove some old Visual Studio versions from PC/ directory http://bugs.python.org/issue16769 opened by brian.curtin #16772: int() accepts float number base http://bugs.python.org/issue16772 opened by serhiy.storchaka #16773: int() half-accepts UserString http://bugs.python.org/issue16773 opened by serhiy.storchaka #16774: Additional recipes for itertools docs http://bugs.python.org/issue16774 opened by kachayev #16776: Document PyCFunction_New and PyCFunction_NewEx functions http://bugs.python.org/issue16776 opened by asvetlov #16778: Logger.findCaller needs to be smarter http://bugs.python.org/issue16778 opened by glynnc #16781: execfile/exec execution in other than global scope uses locals http://bugs.python.org/issue16781 opened by techtonik #16782: No curses.initwin: Incorrect package docstring for curses http://bugs.python.org/issue16782 opened by ballingt #16783: sqlite3 accepts strings it cannot return http://bugs.python.org/issue16783 opened by William.D..Colburn #16784: Int tests enhancement and refactoring http://bugs.python.org/issue16784 opened by serhiy.storchaka #16785: Document the fact that constructing OSError with erron returns http://bugs.python.org/issue16785 opened by asvetlov #16786: argparse doesn't offer localization interface for "version" ac http://bugs.python.org/issue16786 opened by thorsten #16787: asyncore.dispatcher_with_send - increase the send buffer size http://bugs.python.org/issue16787 opened by neologix #16795: Patch: some changes to AST to make it more useful for static l http://bugs.python.org/issue16795 opened by scummos #16798: DTD not checked http://bugs.python.org/issue16798 opened by txomon #16799: switch regrtest from getopt options to argparse Namespace http://bugs.python.org/issue16799 opened by chris.jerdonek #16800: tempfile._get_default_tempdir() leaves files behind when HD is http://bugs.python.org/issue16800 opened by kichik #16801: Preserve original representation for integers / floats in docs http://bugs.python.org/issue16801 opened by larry #16802: fileno argument to socket.socket() undocumented http://bugs.python.org/issue16802 opened by sbt Most recent 15 issues with no replies (15) == #16802: fileno argument to socket.socket() undocumented http://bugs.python.org/issue16802 #16799: switch regrtest from getopt options to argparse Namespace http://bugs.python.org/issue16799 #16798: DTD not checked http://bugs.python.org/issue16798 #16795: Patch: some changes to AST to make it more useful for static l http://bugs.python.org/issue16795 #16786: argparse doesn't offer localization interface for "version" ac http://bugs.python.org/issue16786 #16783: sqlite3 accepts strings it cannot return http://bugs.python.org/issue16783 #16782: No curses.initwin: Incorrect package docstring for curses http://bugs.python.org/issue16782 #16776: Document PyCFunction_New and PyCFunction_NewEx functions http://bugs.python.org/issue16776 #16773: int() half-accepts UserString http://bugs.python.org/issue16773 #16763: test_ssl with connect_ex don't handle unreachable server corre http://bugs.python.org/issue16763 #16762: test_subprocess failure on OpenB
Re: [Python-Dev] Draft PEP for time zone support.
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote: > > That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`. > As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any opinions against that? There is no TimeZoneError today, and it would only be used for this UnknownTimeZoneError, so I'm not sure it has much value. //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP for time zone support.
On Dec 28, 2012, at 07:02 PM, Lennart Regebro wrote: >On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote: > >> >> That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`. >> > >As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any >opinions against that? There is no TimeZoneError today, and it would only be >used for this UnknownTimeZoneError, so I'm not sure it has much value. Agreed. If this is the only exception defined in the module, it sounds fine to me. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP for time zone support.
On 12/28/2012 1:02 PM, Lennart Regebro wrote: On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw mailto:[email protected]>> wrote: That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`. As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any opinions against that? Since the erroneous value is used as a key for a database lookup, and the error is probably detected by trying the lookup, I think that is ok. even if the user does not use []s. There is no TimeZoneError today, and it would only be used for this UnknownTimeZoneError, so I'm not sure it has much value. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 431 Time zone support improvements - Update
Happy Holidays! Here is the update of PEP 431 with the changes that emerged
after the earlier discussion.
A raw download is here:
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
PEP: 431
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Regebro
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Dec-2012
Post-History: 11-Dec-2012, 28-Dec-2012
Abstract
This PEP proposes the implementation of concrete time zone support in the
Python standard library, and also improvements to the time zone API to deal
with ambiguous time specifications during DST changes.
Proposal
Concrete time zone support
--
The time zone support in Python has no concrete implementation in the
standard library outside of a tzinfo baseclass that supports fixed offsets.
To properly support time zones you need to include a database over all time
zones, both current and historical, including daylight saving changes.
But such information changes frequently, so even if we include the last
information in a Python release, that information would be outdated just a
few months later.
Time zone support has therefore only been available through two third-party
modules, ``pytz`` and ``dateutil``, both who include and wrap the "zoneinfo"
database. This database, also called "tz" or "The Olsen database", is the
de-facto standard time zone database over time zones, and it is included in
most Unix and Unix-like operating systems, including OS X.
This gives us the opportunity to include the code that supports the zoneinfo
data in the standard library, but by default use the operating system's copy
of the data, which typically will be kept updated by the updating mechanism
of the operating system or distribution.
For those who have an operating system that does not include the zoneinfo
database, for example Windows, the Python source distribution will include a
copy of the zoneinfo database, and a distribution containing the latest
zoneinfo database will also be available at the Python Package Index, so it
can be easily installed with the Python packaging tools such as
``easy_install`` or ``pip``. This could also be done on Unices that are no
longer recieving updates and therefore has an outdated database.
With such a mechanism Python would have full time zone support in the
standard library on any platform, and a simple package installation would
provide an updated time zone database on those platforms where the zoneinfo
database isn't included, such as Windows, or on platforms where OS updates
are no longer provided.
The time zone support will be implemented by making the ``datetime`` module
into a package, and creating a new submodule called `timezone``, based on
Stuart Bishop's ``pytz`` module.
Getting the local time zone
---
On Unix there is no standard way of finding the name of the time zone that is
being used. All the information that is available is the time zone
abbreviations, such as ``EST`` and ``PDT``, but many of those abbreviations
are ambigious and therefore you can't rely on them to figure out which time
zone you are located in.
There is however a standard for finding the compiled time zone information
since it's located in ``/etc/localtime``. Therefore it is possible to create
a local time zone object with the correct time zone information even though
you don't know the name of the time zone. A function in ``datetime`` should
be provided to return the local time zone.
The support for this will be made by integrating Lennart Regebro's
``tzlocal`` module into the new ``timezone`` module.
For Windows it will look up the local Windows time zone name, and use a
mapping between Windows time zone names and zoneinfo time zone names provided
by the Unicode consortium to convert that to a zoneinfo timezone.
The mapping should be updated before each major or bugfix release, scripts
for doing so will be provided in the ``Tools/`` directory.
Ambiguous times
---
When changing over from daylight savings time the clock is turned back one
hour. This means that the times during that hour happens twice, once without
DST and then once with DST. Similarily, when changing to daylight savings
time, one hour goes missing.
The current time zone API can not differentiating between the two ambiguous
times during a change from DST. For example, in Stockholm the time of
2012-11-28 02:00:00 happens twice, both at UTC 2012-11-28 00:00:00 and also
at 2012-11-28 01:00:00.
The current time zone API can not disambiguate this and therefore it's
unclear which time should be returned::
# This could be either 00:00 or 01:00 UTC:
>>> dt = datetime(2012, 10, 28, 2, 0, tzinfo=timezone('Europe/Stockholm'))
# But we can not specify which:
>>> dt.astimezone(timezone('UTC'))
datetime.datetime(2012, 10, 28, 1, 0, tzinfo=)
``pytz`` solved this problem by adding
Re: [Python-Dev] PEP 431 Time zone support improvements - Update
On 28 Dec, 2012, at 21:23, Lennart Regebro wrote: > Happy Holidays! Here is the update of PEP 431 with the changes that emerged > after the earlier discussion. Why is the new timezone support added in a submodule of datetime? Adding the new function and exception to datetime itself wouldn't clutter the API that much, and datetime already contains some timezone support (datetime.tzinfo). Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: PEP 432 updates in response to initial comments
On Fri, 28 Dec 2012 14:54:55 -0500 Terry Reedy wrote: > > 4. Running ./python_d from within a PCBuild/python_d interactive window > and on a regular disk averages .10 seconds. The slowdown is probably a > mixture of disk access and extra debug code, but is not bad. There is no > flashing (probably because there already is a window, whereas on Windows > IDLE runs code within a windowless pythonw process) and ^C works. This > is definitely a better environment for this type of test ;-). You'd get more meaningful numbers by using a non-debug build (PCBuild/python.exe, I guess). Our debugging additions + the lack of compiler optimizations butcher performance. It would be extra nice if you had numbers comparing 3.3, 3.2 and 2.7 (under Windows, that is). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems
I'm trying to track down why bundlebuilder no longer works with python 2.7 to create runnable Mac OS X apps. I have got as far as seeing that imports of modules are failing. What I see is that sys.path does not contain all the elements from the PYTHONPATH variable. No matter what I put in PYTHONPATH only the first element is in sys.path. In detail here is what I'm using to test this: $ export PYTHONHOME=/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources $ export PYTHONPATH=/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources:/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/Modules.zip $ python2.7 -c "import sys;print sys.path" ['', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources'] $ python2.6 -c "import sys;print sys.path" 'import site' failed; use -v for traceback ['', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/Modules.zip', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python26.zip', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/plat-darwin', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/plat-mac', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/plat-mac/lib- scriptpackages', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/lib-tk', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/lib-old', '/Users/barry/wc/svn/pysvn/WorkBench/Kit/MacOSX/tmp/pysvn_workbench_svn178-1.6.6-0-x86_64/WorkBench.app/Contents/Resources/lib/python2.6/lib-dynload'] Any insight into what has changed and what might need changing in bundlebuilder would be appreciated. Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems
On Fri, 28 Dec 2012 21:39:56 + Barry Scott wrote: > I'm trying to track down why bundlebuilder no longer works with python 2.7 > to create runnable Mac OS X apps. > > I have got as far as seeing that imports of modules are failing. > > What I see is that sys.path does not contain all the elements from the > PYTHONPATH variable. > > No matter what I put in PYTHONPATH only the first element is in sys.path. I can't reproduce under Linux: $ PYTHONPATH=/x:/y python -Sc "import sys; print(sys.path)" ['', '/x', '/y', '/usr/lib/python27.zip', '/usr/lib64/python2.7/', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload'] Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] question about packaging
A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of its current state. Can someone point me to the right mailing list, and maybe a status page or something so I can start figuring out where we might be able to help? Thanks, Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems
You did not set PYTHONHOME that effects the code in calculate_path a lot. Also there is platform specific code in tht code. Barry On 28 Dec 2012, at 22:30, Antoine Pitrou wrote: > On Fri, 28 Dec 2012 21:39:56 + > Barry Scott wrote: >> I'm trying to track down why bundlebuilder no longer works with python 2.7 >> to create runnable Mac OS X apps. >> >> I have got as far as seeing that imports of modules are failing. >> >> What I see is that sys.path does not contain all the elements from the >> PYTHONPATH variable. >> >> No matter what I put in PYTHONPATH only the first element is in sys.path. > > I can't reproduce under Linux: > > $ PYTHONPATH=/x:/y python -Sc "import sys; print(sys.path)" > ['', '/x', '/y', '/usr/lib/python27.zip', '/usr/lib64/python2.7/', > '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', > '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload'] > > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/barry%40barrys-emacs.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] question about packaging
There's the distutil mailing list: http://mail.python.org/mailman/listinfo/distutils-sig Doug Hellmann wrote: A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of its current state. Can someone point me to the right mailing list, and maybe a status page or something so I can start figuring out where we might be able to help? Thanks, Doug ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/a.cavallo%40cavallinux.eu ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHONPATH processing change from 2.6 to 2.7 and Mac bundle builder problems
In article <[email protected]>, Barry Scott wrote: > You did not set PYTHONHOME that effects the code in calculate_path a lot. > Also there is platform specific code in tht code. > On 28 Dec 2012, at 22:30, Antoine Pitrou wrote: > > On Fri, 28 Dec 2012 21:39:56 + > > Barry Scott wrote: > >> I'm trying to track down why bundlebuilder no longer works with python 2.7 > >> to create runnable Mac OS X apps. > >> > >> I have got as far as seeing that imports of modules are failing. > >> > >> What I see is that sys.path does not contain all the elements from the > >> PYTHONPATH variable. > >> > >> No matter what I put in PYTHONPATH only the first element is in sys.path. > > > > I can't reproduce under Linux: > > > > $ PYTHONPATH=/x:/y python -Sc "import sys; print(sys.path)" > > ['', '/x', '/y', '/usr/lib/python27.zip', '/usr/lib64/python2.7/', > > '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', > > '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload'] Barry, I think this discussion should be taking place on the bug tracker (http://bugs.python.org), rather than in python-dev. bundlebuilder is unique to OS X and fairly esoteric. Please open an issue there and include a sample of how you created an app with bundlebuilder and what Python 2.7 version you are using and what version of OS X. Thanks! -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP for time zone support.
On 29/12/12 05:02, Lennart Regebro wrote: On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote: That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`. As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any opinions against that? The PEP says: * New function :``timezone(name=None, db_path=None)`` This function takes a name string that must be a string specifying a valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11". It isn't 100% clear to me from the PEP what a valid name string would be, but I assume that it will accept anything that the time.tzset function will accept: http://docs.python.org/3/library/time.html#time.tzset If so, then valid "name strings" may be either: - strings which define the timezone rule explicitly, e.g: 'AEST-10AEDT-11,M10.5.0,M3.5.0' - or for convenience, rules already defined in your OS's timezone database: 'Australia/Melbourne' In either case, I don't think KeyError is the appropriate exception type. I think that if I were to see a time zone string such as: 'Europe/Melbourne' # no such place 'Eorupe/Stockhome' # misspelled 'Etc/GMT+999' # invalid offset 'AEST+10ASDT+11,M1050,M350' # invalid starting and ending dates '*&vbegs156s^g' # utter rubbish I would describe it as an *invalid* timezone, not a "missing" timezone. So ValueError is a more appropriate base exception than KeyError. There is no TimeZoneError today, and it would only be used for this UnknownTimeZoneError, so I'm not sure it has much value. In that case, can you rename UnknownTimeZoneError to TimeZoneError, which is shorter and easier to read, write and remember? (We have KeyError rather than UnknownKeyError, NameError rather than UnknownNameError, etc.) -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP for time zone support.
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano wrote: > The PEP says: > > * New function :``timezone(name=None, db_path=None)`` > > > This function takes a name string that must be a string specifying a > valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or > "Etc/GMT+11". > > > It isn't 100% clear to me from the PEP what a valid name string would be, > but I assume that it will accept anything that the time.tzset function > will accept: > No, valid names are the names of time zones in the zoneinfo database. There isn't really any usecase for defining up your own rules as that would mean that you want a time zone that doesn't exist, which seems a bit pointless. :-) (We have KeyError rather than UnknownKeyError, NameError rather than > UnknownNameError, etc.) > Sure, but what would otherwise a KeyError be unless an unkown or non-existing key? //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 431 Time zone support improvements - Update
On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren wrote: > > On 28 Dec, 2012, at 21:23, Lennart Regebro wrote: > > > Happy Holidays! Here is the update of PEP 431 with the changes that > emerged after the earlier discussion. > > Why is the new timezone support added in a submodule of datetime? Because several people wanted it that way and nobody objected. > Adding the new > function and exception to datetime itself wouldn't clutter the API that > much It will make the datetime.py twice as long though, and the second longest module in the stdlib, beaten only by decimal.py. Perhaps this is not a problem. //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 431 Time zone support improvements - Update
2012/12/28 Lennart Regebro : > It will make the datetime.py twice as long though, and the second longest > module in the stdlib, beaten only by decimal.py. Perhaps this is not a > problem. No one ever accused datetime manipulation of being simple. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 431 Time zone support improvements - Update
On Sat, Dec 29, 2012 at 6:23 AM, Lennart Regebro wrote: > Happy Holidays! Here is the update of PEP 431 with the changes that emerged > after the earlier discussion. > > A raw download is here: > https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt For UI purposes, "pytz" has some helpers to get lists of timezone names (all, common and country specific): http://pytz.sourceforge.net/#helpers Is there a specific reason you chose to exclude those from the PEP? > Discussion > == > > Should the windows installer include the data package? > -- > > It has been suggested that the Windows installer should include the data > package. This would mean that an explicit installation no longer would be > needed on Windows. On the other hand, that would mean that many using > Windows > would not be aware that the database quickly becomes outdated and would not > keep it updated. I'm still a fan of *always* shipping fallback tzdata, regardless of platform. The stdlib would then look in three places for timezone data when datetime.timezone was first imported: 1. the "tzdata-update" database 2. the OS provided database 3. the fallback database Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
