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
On Thu, Feb 18, 2010 at 03:48, Michael Foord fuzzy...@voidspace.org.uk 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
-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
On Thu, Feb 18, 2010 at 4:38 PM, Lennart Regebro rege...@gmail.com 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
On Tue, Feb 16, 2010 at 1:52 PM, Victor Stinner
victor.stin...@haypocalc.com 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
On Thu, Feb 18, 2010 at 7:41 AM, anatoly techtonik techto...@gmail.com 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
On Thu, Feb 18, 2010 at 11:29, Stuart Bishop stu...@stuartbishop.net 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
On Thu, Feb 18, 2010 at 13:41, anatoly techtonik techto...@gmail.com 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
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
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
On Sat, Feb 13, 2010 at 12:12 AM, Maciej Fijalkowski fij...@gmail.com 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,
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
On Thu, Feb 18, 2010 at 22:42, Martin v. Löwis mar...@v.loewis.de 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
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://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
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
On Fri, Feb 19, 2010 at 4:45 AM, Lennart Regebro rege...@gmail.com wrote:
On Thu, Feb 18, 2010 at 22:42, Martin v. Löwis mar...@v.loewis.de 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,
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
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
On Fri, Feb 19, 2010 at 12:11 PM, Lennart Regebro rege...@gmail.com 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
On Fri, Feb 19, 2010 at 7:40 AM, Martin v. Löwis mar...@v.loewis.de 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
21 matches
Mail list logo
