[issue2124] xml.sax and xml.dom fetch DTDs by default

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 benefit from

[issue1667546] Time zone-capable variant of time.localtime

Paul Boddie p...@boddie.org.uk 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

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

New submission from Paul Boddie p...@boddie.org.uk: 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

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

Paul Boddie p...@boddie.org.uk 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

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

Paul Boddie p...@boddie.org.uk 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 implements

[issue7942] Inconsistent error types/messages for __len__ (and __nonzero__) between old and new-style classes

Paul Boddie p...@boddie.org.uk 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

[issue762963] timemodule.c: Python loses current timezone

Paul Boddie p...@boddie.org.uk 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 failing tests, too

[issue2124] xml.sax and xml.dom fetch DTDs by default

Paul Boddie p...@boddie.org.uk 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

[issue762963] timemodule.c: Python loses current timezone

Paul Boddie p...@boddie.org.uk 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

[issue1667546] Time zone-capable variant of time.localtime

Paul Boddie p...@boddie.org.uk added the comment: On Wednesday 13 June 2012 23:51:25 Alexander Belopolsky wrote: Alexander Belopolsky alexander.belopol...@gmail.com added the comment: I've simplified Paul's patch by removing timegm and mktimetz functions. Also, platforms that don't support

[issue5340] Change in cgi behavior breaks existing software

Paul Boddie p...@boddie.org.uk 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