Paul Boddie added the comment:
On Wednesday 13 June 2012 23:51:25 Alexander Belopolsky wrote:
> Alexander Belopolsky added the comment:
>
> I've simplified Paul's patch by removing timegm and mktimetz functions.
> Also, platforms that don't support tm_zone are u
Paul Boddie added the comment:
Note that Python 3 provided a good opportunity for doing the minimal amount of
work here - just stop things from accessing remote DTDs - but I imagine that
even elementary standard library improvements of this kind weren't made (let
alone the more exte
Paul Boddie added the comment:
I don't understand how this bug and its patches are still active. It's
difficult for me to remember what I was doing in early 2007 when I started
working on issue #1667546, but I can well imagine that it was in response to
this and a number of re
Paul Boddie added the comment:
Speaking for myself, I'm not sure whether I'm really the person to push this
further, at least, although others may see it as a worthy sprinting topic. In
principle, adding the extra fields is the right thing to do, merely because it
exposes things fr
Paul Boddie added the comment:
Well, this still doesn't work for me. I'm running Kubuntu 8.04 (libc6 package
version 2.7-10ubuntu5) and reside in the CEST time zone, yet attempting to
display the time zone always seems to give "+". Here are the
Paul Boddie added the comment:
Actually, in the issue reported, the initial problem occurs in the evaluation
of an object in a boolean context (and the subsequent problem occurs with an
explicit len invocation):
http://www.selenic.com/pipermail/mercurial/2010-February/030066.html
Presumably
Paul Boddie added the comment:
I don't disagree that OverflowError describes what's happening, but the need to
convert to an int in the first place is a detail of the machine - you'd have to
know that this is a limitation of whatever internal "protocol" CPython
imple
Paul Boddie added the comment:
I would have expected a more accurate error message for the new-style class. In
the original message which brought this to my attention, the cause was not
particularly obvious:
http://www.selenic.com/pipermail/mercurial/2010-February/030066.html
I concede that
New submission from Paul Boddie :
As noted here:
http://www.selenic.com/pipermail/mercurial/2010-February/030068.html
This is probably documented somewhere, and there may even be a good reason for
the difference, but old-style classes raise TypeError when __len__ returns a
non-int, whereas
Paul Boddie added the comment:
The issue of distinguishing between query-originating parameters and
form-originating parameters has been around for a very long time, and
in my own work, especially where the cgi module has been used, I've
been careful to distinguish between the two types a
Paul Boddie added the comment:
(Andrew, thanks for making a bug, and apologies for not reporting this
in a timely fashion.)
Although an in-memory caching solution might seem to be sufficient, if
one considers things like CGI programs, it's clear that such programs
aren't going to be
11 matches
Mail list logo
