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.
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 o
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 elementtre
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 versio
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 stdli
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
(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
> 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
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 tim
>> 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 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 real
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 t
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
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 a
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,
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 w
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,
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
-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 va
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
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 no
21 matches
Mail list logo
