[Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
Hello, On November 2006 and September 2007 Fredrik proposed to update "xml.etree" in Python 2.6 with the upcoming version 1.3. Now we are three years later, and the version shipped with 2.7alpha3 is 1.2.6. http://bugs.python.org/issue1602189#msg54944 http://bugs.python.org/issue1143 This would not be an issue, without the numerous bug reports accumulating on bugs.python.org. Most of these reports are waiting for the 1.3 release. Three months ago I worked on some of these issues, and after fixing them separately, I proposed a patch which merges the latest 1.3 snapshot (released in 2007) within the standard library. The aim is to provide a bug-free version of ElementTree/cElementTree in the standard library. For this purpose, I grew the test suite from 300 lines to 1800 lines, using both the tests from upstream and the tests proposed by Neil Muller on issue #6232. To ensure consistency, now the test_suite for the C implementation is the same as the Python implementation. http://bugs.python.org/issue6472 We are still interested with the upcoming release of ElementTree, but we should adopt a pragmatic approach: the xml.etree.ElementTree needs to be fixed for all Python users, even if 1.3 is not ready before 2.7beta. This is the only purpose of the patch. The patch sticks as much as possible to the upstream library. Initially I kept all the new features of the 1.3 branch in the patch. It should ease the integration of 1.3 final when it is released. With the last comment from Fredrik, I think to be more conservative: I plan to split out the experimental C API from the package. It is not required for the bug-fix release, and there's some risk of incompatibility with the final design of the API, which is still secret. As a side-effect, the patch will add some features and methods from the 1.3 branch (some of them where requested in the bug tracker): - ET.fromstringlist(), ET.tostringlist() - Element.extend(), Element.iter(), Element.itertext() - new selector engine - extended slicing However the highlighted features of this patch are: - to fix many bugs which were postponed because of 1.3 release - to ensure consistency between C and Python implementations (with tests) - to provide a better test coverage The patch is uploaded on Rietveld for review. The 3.x version of the patch will be updated after 2.x is merged in trunk. The patch covers documentation, too. http://codereview.appspot.com/207048/show It's time to comment and review. The proposed plan is to merge the patch in trunk before 2.7 alpha4. Best regards, -- Florent Xicluna ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 03:48, Michael Foord wrote: > Some of the Linux distributions *already* patch pytz to use the system > information, which they keep updated separately. Yes. And what problem does including pytz in the stdlib solve? > That information is also > available from the system on Mac OS and Windows. It is not available on Windows in any reasonable and useable form. > It would seem to be very > useful to have a version of pytz that defaults to using the system > information if available, has a mechanism for using separate data for > systems that don't provide the information or raises an error when neither > system information nor separate data is available. Pytz has mechanisms for that, perhaps they should be more easily useable. Perhaps it should even default to using the system Olsen database if there is one. But the discussion was if it should be included in the standard library, and nobody still has explain what problem that would solve. If it doesn't solve a problem, it shouldn't be done, as it also is going to create problems, because everything does. :) > The data could then still be available and released regularly without being > tied to the Python release schedule. Which it already is. So no problem solved. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
-On [20100217 23:48], s...@pobox.com (s...@pobox.com) wrote: >My guess is the data are updated several times per year, not the code. Can >they not be separated? The bulk of the original timezone package is data for the timezones. Last year saw close to 26 releases for this. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B When you pass through, no one can pin you down, no one can call you back... ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 4:38 PM, Lennart Regebro wrote: If it doesn't solve a problem, it shouldn't be done, as it also is going to create problems, because everything does. :) I think a tzinfo implementation in the standard library that uses the system timezone database would be useful to a great many people, providing a standard way of mapping a string to a tzinfo instance. The number of frameworks requiring pytz as a dependency demonstrate this. It is unfortunate that those strings would be platform specific. For most applications this doesn't matter - you are reading the key from a config file or allowing the user to select from a list of possible values. For applications where that actually matters it would be simple enough to install and maintain a local zoneinfo database, for example by allowing pytz to plug itself in or just a well known location in the Python tree where valid compiled zoneinfo files can be copied in from a nearby unix-like system or pytz tarball. As the pytz maintainer, this would help me solve a long standing problem. Currently, pytz tzinfo instances don't really follow the documented tzinfo interface (in order to allow localized datetime arithmetic to be always correct instead of good enough). This is a source of confusion to many users who don't need this level of accuracy. It would be great if the standard library provided a tzinfo implementation that was good enough for the vast majority of users, and for people who do care they can continue to use pytz.timezone() to retrieve the anal tzinfo implementation. Users will be happier as they will have fewer bugs in their code. The alternative for me is to eventually split pytz, somehow providing the simpler interface that works exactly as documented in the Python reference and the anal interface that works per the pytz README (in hindsight, it should have been this way from day 1). I'm happy to work on this if there is agreement. I'm happy to relicense any pytz code used as a basis if necessary (currently MIT), and dateutil is already PSF licensed if that seems a better starting point. -- Stuart Bishop http://www.stuartbishop.net/ signature.asc Description: OpenPGP digital signature ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Tue, Feb 16, 2010 at 1:52 PM, Victor Stinner wrote: >> So far, Python timezone handling is far from "pythonic". There is no >> function to get current UTC offset, (...) > > There is the time.timezone attribute: UTC offset in seconds. It is correct only if DST is not in effect. On Tue, Feb 16, 2010 at 5:26 PM, Tres Seaver wrote: > > s...@pobox.com wrote: >> >> While incorporating dateutil into the core would be nice (in my opinion at >> least), I was really thinking of pytz: http://pytz.sourceforge.net/ > > Because timezones are defined politically, they change frequently. pytz > is released frequently (multiple times per year) to accomodate those > changes: I can't see any way to preserve that flexibility if the > package were part of stdlib. Actual TZ information can be shipped with every Python release, but.. If pytz package is available and it's newer - library functions may use its data instead. Of course, this should be documented as official way to maintain TZ info up-to-date. If pytz to be included in standard library - it should still be distributed as separate package to provide more frequent TZ updates and updates to older Python versions. On Wed, Feb 17, 2010 at 1:32 PM, Lennart Regebro wrote: > There is no need to stick Pytz in the standard library. It's available > on PyPI, updated frequently, etc. What we can do is point to it from > the documentation. It will still require workarounds and bridges to make API in user scripts convenient, i.e. try: import pytz mydatetime = PytzDatetime() catch ImportError: mydatetime = ClassicDatetime() The goal is to reduce workarounds and avoid repeated code in Python scripts. Leaving pytz aside, does everybody feel comfortable with setting a Wave for API design of date/time issues and the stuff to be done? If there will be an API draft and current list of stuff - I can try to do some work in "offline" mode. -- anatoly t. ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 7:41 AM, anatoly techtonik wrote: > It will still require workarounds and bridges to make API in user > scripts convenient, i.e. I'm not entirely sure what you intended the "It" to refer to here. My take on this is that bundling a version of pytz in the standard library will simply generate more ways to deal with timezones. Using pytz as an external dependency is easy and provides a high level of update support. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 11:29, Stuart Bishop wrote: > I think a tzinfo implementation in the standard library that uses the system > timezone database would be useful to a great many people, providing a > standard way of mapping a string to a tzinfo instance. Well, that wouldn't work on Windows, which would be a bit strange. So yes, on some systems it would mean you now have pytz in the standard library, while you don't on others. That's going to cause problems, while it doesn't actually solve any problem except "I need to install pytz", which isn't much of a problem. > The number of > frameworks requiring pytz as a dependency demonstrate this. They are going to still need to require pytz, or rather the data part of it. > It is unfortunate that those strings would be platform specific. For most > applications this doesn't matter - you are reading the key from a config > file or allowing the user to select from a list of possible values. Well, the problem in finding your won timezone has been documented in one of the links I sent before. But that's another problems, solved by the tzfile/tzwin implementations discussed previously. > As the pytz maintainer, this would help me solve a long standing problem. > Currently, pytz tzinfo instances don't really follow the documented tzinfo > interface (in order to allow localized datetime arithmetic to be always > correct instead of good enough). This is a source of confusion to many users > who don't need this level of accuracy. It would be great if the standard > library provided a tzinfo implementation that was good enough for the vast > majority of users, and for people who do care they can continue to use > pytz.timezone() to retrieve the anal tzinfo implementation. Users will be > happier as they will have fewer bugs in their code. The alternative for me > is to eventually split pytz, somehow providing the simpler interface that > works exactly as documented in the Python reference and the anal interface > that works per the pytz README (in hindsight, it should have been this way > from day 1). I understand the need for different API's but can't the extended part that doesn't behave like timezone be separate methods? I don't *mind* pytz in the standardlibrary, I just don't really see how it solves any problems, while I can see how it creates them. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 13:41, anatoly techtonik wrote: > It will still require workarounds and bridges to make API in user > scripts convenient, i.e. > > try: > import pytz > mydatetime = PytzDatetime() > catch ImportError: > mydatetime = ClassicDatetime() Only if you want to work both with and without pytz. So don't. Just require pytz. I don't see the problem with that. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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
[Python-Dev] Buffered streams design + raw io gotchas
Hello, As I continue experimenting with advanced streams, I'm currently beginning an important modification of io's Buffered and Text streams (removal of locks, adding of methods...), to fit the optimization process of the whole library. However, I'm now wondering what the idea is behind the 3 main buffer classes : Bufferedwriter, Bufferedreader and Bufferedrandom. The i/o PEP claimed that the two first ones were for sequential streams only, and the latter for all kinds of seekable streams; but as it is implemented, actually the 3 classes can be returned by open() for seekable files. Am I missing some use case in which this distinction would be useful (for optimizations ?) ? Else, I guess I should just create a RSBufferedStream class which handles all kinds of situations, raising InsupportedOperation exceptions whenever needed after all, text streams act that way (there is no TextWriter or TextReader stream), and they seem fine. Also, io.open() might return a raw file stream when we set buffering=0. The problem is that raw file streams are NOT like buffered streams with a buffer limit of zero : raw streams might fail writing/reading all the data asked, without raising errors. I agree this case should be rare, but it might be a gotcha for people wanting direct control of the stream (eg. for locking purpose), but no silently incomplete read/write operation. Shouldn't we rather return a "write through" buffered stream in this case "buffering=0", to cleanly handle partial read/write ops ? regards, Pascal PS : if you have 3 minutes, I'd be very interested by your opinion on the "advanced modes" draft below. Does it seem intuitive to you ? In particular, shouldn't the "+" and "-" flags have the opposite meaning ? http://bytebucket.org/pchambon/python-rock-solid-tools/wiki/rsopen.html ___ 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
Re: [Python-Dev] Buffered streams design + raw io gotchas
IIRC here is the use case for buffered reader/writer vs. random: a disk file opened for reading and writing uses a random access buffer; but a TCP stream stream, while both writable and readable, should use separate read and write buffers. The reader and writer don't have to worry about reversing the I/O direction. But maybe I'm missing something about your question? --Guido On Thu, Feb 18, 2010 at 1:59 PM, Pascal Chambon wrote: > Hello, > > As I continue experimenting with advanced streams, I'm currently beginning > an important modification of io's Buffered and Text streams (removal of > locks, adding of methods...), to fit the optimization process of the whole > library. > However, I'm now wondering what the idea is behind the 3 main buffer classes > : Bufferedwriter, Bufferedreader and Bufferedrandom. > > The i/o PEP claimed that the two first ones were for sequential streams > only, and the latter for all kinds of seekable streams; but as it is > implemented, actually the 3 classes can be returned by open() for seekable > files. > > Am I missing some use case in which this distinction would be useful (for > optimizations ?) ? Else, I guess I should just create a RSBufferedStream > class which handles all kinds of situations, raising InsupportedOperation > exceptions whenever needed after all, text streams act that way (there > is no TextWriter or TextReader stream), and they seem fine. > > Also, io.open() might return a raw file stream when we set buffering=0. The > problem is that raw file streams are NOT like buffered streams with a buffer > limit of zero : raw streams might fail writing/reading all the data asked, > without raising errors. I agree this case should be rare, but it might be a > gotcha for people wanting direct control of the stream (eg. for locking > purpose), but no silently incomplete read/write operation. > Shouldn't we rather return a "write through" buffered stream in this case > "buffering=0", to cleanly handle partial read/write ops ? > > regards, > Pascal > > PS : if you have 3 minutes, I'd be very interested by your opinion on the > "advanced modes" draft below. > Does it seem intuitive to you ? In particular, shouldn't the "+" and "-" > flags have the opposite meaning ? > http://bytebucket.org/pchambon/python-rock-solid-tools/wiki/rsopen.html > > > > ___ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
On Sat, Feb 13, 2010 at 12:12 AM, Maciej Fijalkowski wrote: > I like this wording far more. It's at the very least far more precise. > Those examples are fair enough (except the fact that PyPy is not 32bit > x86 only, the JIT is). [snip] > "slower than US on some workloads" is true, while not really telling > much to a potential reader. For any X and Y implementing the same > language "X is faster than Y on some workloads" is usually true. > > To be precise you would need to include the above table in the PEP, > which is probably a bit too much, given that PEP is not about PyPy at > all. I'm fine with any wording that is at least correct. I've updated the language: http://codereview.appspot.com/186247/diff2/9005:11001/11002. Thanks for the clarifications. Collin Winter ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
>> That information is also >> available from the system on Mac OS and Windows. > > It is not available on Windows in any reasonable and useable form. That's not true. The registry is readable by any user, and the format is fully documented. Regards, Martin ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Thu, Feb 18, 2010 at 22:42, "Martin v. Löwis" wrote: > That's not true. The registry is readable by any user, and the format is > fully documented. Yes, but they use non-standard locations, and afaik, pytz does not support it. If a stdlib pytz would use this you would have to use different timezone names for Unix and Windows. I don't think that's a good idea. Also, the windows data contains only current timezone data, so for calendars stretching back in time, the Olsen database would be preferable as it keeps history. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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
Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
> It's time to comment and review. Unfortunately, it's not. I strongly object to any substantial change to the code base without explicit approval by Fredrik Lundh. Regards, Martin ___ 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
[Python-Dev] some notes from the first part of the lang summit
(http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html) Note that this was just from the first 15 minutes or so... Some quick notes about the coming plans by the "other" Python implementations from today's Python Language Summit at PyCon 2010: - IronPython: - plan is to do Python 2.7 first, focus for this year - python 3.2 for the end of next year hopefully - other work on IDE stuff - Pynie (i.e. Parrot) -- Allison Randall: - about 4 major features away from pure Python syntax (did dicts last night) - targetting py3k repo and test suite: should be on track for python 3.2 - Jython: - plan to target 2.6 (b/c 2to3 depends on 2.6) - temporarily skip 2.7 and target 3.x (probably 3.2) - then if 3.x adoption isn't fully there, then go back and add Python 2.7 - will require JDK 2.7 for Python 3 support (b/c of new support for dynamic languages) - PyPy (Holger): - plan is Benjamin will port to Python 2.7 in the summer - only have slight deviations from CPython: idea is to merge back with CPython so don't have deviations. Typcically 1 or 2 line changes in ~25 modules. Trent -- Trent Mick trentm at activestate.com http://trentm.com/blog/ ___ 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
Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
Le Thu, 18 Feb 2010 22:46:41 +0100, Martin v. Löwis a écrit : >> It's time to comment and review. > > Unfortunately, it's not. I strongly object to any substantial change to > the code base without explicit approval by Fredrik Lundh. Which most probably puts elementtree in bugfix-only mode. I don't necessarily disagree with such a decision, but it must be quite clear. Regards Antoine. ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Fri, Feb 19, 2010 at 4:45 AM, Lennart Regebro wrote:
On Thu, Feb 18, 2010 at 22:42, "Martin v. Löwis" wrote:
That's not true. The registry is readable by any user, and the format is
fully documented.
Yes, but they use non-standard locations, and afaik, pytz does not
support it. If a stdlib pytz would use this you would have to use
different timezone names for Unix and Windows. I don't think that's a
good idea.
Under Windows the only backend API I'm aware of we could use is tzwin and I
think any standard library inclusion would require this or something similar.
For the standard library, I think it would be great if you could do
'datetime.timezone(some_string)' and get a tzinfo instance suitable for most
use cases which seems no problem for tzwin to provide (platform default DST
information, simple interface with potentially incorrect localized datetime
arithmetic over DST transitions). It is unfortunate that the timezone strings
are platform specific, but I feel that is still better than end users having to
keep updating timezone databases or not supporting non-zoneinfo systems at all.
Even with pytz, the timezone strings are version specific to an extent (we had
a real issue where we updated pytz on our web applications, which changed a
preferred timezone name from Asia/Calcutta to Asia/Kolkata per requests from
our users and as a result our wiki's exploded for some users as they where on
separate boxes using a different pytz release that didn't understand that
timezone string).
It would also be trivial to always look up timezone information from compiled
zoneinfo files in a well known location if the system timezone database cannot
find the requested timezone information. So datetime.timezone('US/Eastern')
would work on Windows if you had installed pytz (I'd update pytz to install its
zoneinfo files into the blessed location). Best of both worlds.
Also, the windows data contains only current timezone data, so for
calendars stretching back in time, the Olsen database would be
preferable as it keeps history.
Sure. I'm not saying pytz will disappear or become unmaintained for people who
need it. I believe most people who are using it now don't need it and I'm sure
there are real bugs in real code out there because of this, as using pytz
correctly requires reading and understanding the pytz documentation.
If this is all too ambitious, tzinfo implementations in the standard library
for UTC and the current system timezone would be a step forward and solve most
real world use cases.
--
Stuart Bishop
http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
___
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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
But is the "You don't have to install it" really such a big problem so
that it's worth the other problems like platform incompatibilities and
such?
In any case, since you want to make a version that can be included and
uses the timezone API, I guess that's a moot question until we have
that version. :)
On Fri, Feb 19, 2010 at 05:59, Stuart Bishop wrote:
> On Fri, Feb 19, 2010 at 4:45 AM, Lennart Regebro wrote:
>>
>> On Thu, Feb 18, 2010 at 22:42, "Martin v. Löwis"
>> wrote:
>>>
>>> That's not true. The registry is readable by any user, and the format is
>>> fully documented.
>>
>> Yes, but they use non-standard locations, and afaik, pytz does not
>> support it. If a stdlib pytz would use this you would have to use
>> different timezone names for Unix and Windows. I don't think that's a
>> good idea.
>
> Under Windows the only backend API I'm aware of we could use is tzwin and I
> think any standard library inclusion would require this or something
> similar. For the standard library, I think it would be great if you could do
> 'datetime.timezone(some_string)' and get a tzinfo instance suitable for most
> use cases which seems no problem for tzwin to provide (platform default DST
> information, simple interface with potentially incorrect localized datetime
> arithmetic over DST transitions). It is unfortunate that the timezone
> strings are platform specific, but I feel that is still better than end
> users having to keep updating timezone databases or not supporting
> non-zoneinfo systems at all. Even with pytz, the timezone strings are
> version specific to an extent (we had a real issue where we updated pytz on
> our web applications, which changed a preferred timezone name from
> Asia/Calcutta to Asia/Kolkata per requests from our users and as a result
> our wiki's exploded for some users as they where on separate boxes using a
> different pytz release that didn't understand that timezone string).
>
> It would also be trivial to always look up timezone information from
> compiled zoneinfo files in a well known location if the system timezone
> database cannot find the requested timezone information. So
> datetime.timezone('US/Eastern') would work on Windows if you had installed
> pytz (I'd update pytz to install its zoneinfo files into the blessed
> location). Best of both worlds.
>
>> Also, the windows data contains only current timezone data, so for
>> calendars stretching back in time, the Olsen database would be
>> preferable as it keeps history.
>
> Sure. I'm not saying pytz will disappear or become unmaintained for people
> who need it. I believe most people who are using it now don't need it and
> I'm sure there are real bugs in real code out there because of this, as
> using pytz correctly requires reading and understanding the pytz
> documentation.
>
>
> If this is all too ambitious, tzinfo implementations in the standard library
> for UTC and the current system timezone would be a step forward and solve
> most real world use cases.
>
> --
> Stuart Bishop
> http://www.stuartbishop.net/
>
>
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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
Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
Antoine Pitrou wrote: > Le Thu, 18 Feb 2010 22:46:41 +0100, Martin v. Löwis a écrit : >>> It's time to comment and review. >> Unfortunately, it's not. I strongly object to any substantial change to >> the code base without explicit approval by Fredrik Lundh. > > Which most probably puts elementtree in bugfix-only mode. I don't > necessarily disagree with such a decision, but it must be quite clear. My point is that the decision as already made when ElementTree was incorporated into the standard library; it's the same policy for most code that Fredrik Lundh has contributed (and which he still maintains outside the standard library as well). He has made it fairly clear on several occasions that this is how he expects things to work, and unless we want to truly fork the code, we should comply. Regards, Martin ___ 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
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Fri, Feb 19, 2010 at 12:11 PM, Lennart Regebro wrote: > But is the "You don't have to install it" really such a big problem so > that it's worth the other problems like platform incompatibilities and > such? I don't think there are any platform incompatibilities - it will work as documented on all platforms. You lose the ability to assume that two identical pytz versions on different platforms can use the same timezone strings, but gain the ability that system timezone strings can be used with Python. > In any case, since you want to make a version that can be included and > uses the timezone API, I guess that's a moot question until we have > that version. :) As I understand it dateutil pretty much already provides what I'm describing. -- Stuart Bishop http://www.stuartbishop.net/ ___ 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
Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
On Fri, Feb 19, 2010 at 7:40 AM, "Martin v. Löwis" wrote: >> Which most probably puts elementtree in bugfix-only mode. I don't >> necessarily disagree with such a decision, but it must be quite clear. The current situation is even worse than bugfix-only mode. Even bugfixes struggle to make it in. > My point is that the decision as already made when ElementTree was > incorporated into the standard library; it's the same policy for most > code that Fredrik Lundh has contributed (and which he still maintains > outside the standard library as well). He has made it fairly clear on > several occasions that this is how he expects things to work, and unless > we want to truly fork the code, we should comply. We need someone to maintain the copy of ElementTree in the Python repository. Ideally this means pulling upgrades and bugfixes from Fredrik's repository every now and then. If the goals of Python ElementTree and Fredrik ElementTree diverge I don't see a problem with an amicable fork. Fredrik and Python ElementTree do have rather different constraints (for example, Python ElementTree has fewer opportunities for breaking backwards compatibility). Schiavo Simon ___ 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
