[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 tm_zone are unaffected. I think you may have forgotten to remove docstring references to those functions. Nice to see some progress on the issue, though, and it's probably good to solve one problem at a time in this way, too. Paul -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1667546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the more extensive standard library changes I advocated), so there's going to be a backwards compatibility situation regardless of which Python series is involved now, unfortunately. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of related bugs. Looking at #1667546, it's clear that the work required to handle time zones is not at all as trivial as the patches attached to this issue appear to be. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue762963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 things from struct tm which were missing and which influence the other functions depending on it. The only things remaining are to make sure that existing code doesn't change its behaviour with these new fields, and that the new fields work together with the time functions as expected. Thus, testing is the most important thing now, I think. For the bigger picture, which shouldn't be discussed here, Python's way of handling times and dates probably needs improvement - this has been discussed already (a reference for anyone not involved is Anatoly's initial message in one recent discussion: http://mail.python.org/pipermail/python-dev/2010-February/097710.html) - and I think usage of pytz is a step in the right direction, although it does not eliminate the need to learn about time zones (UTC, CET...), time regimes (Europe/Oslo, America/New_York...), floating times, and zone transitions (and ambiguous times). Extending Python library support is potentially a sprinting topic, but not really a topic for discussion around this patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1667546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: == FAIL: test_tm_gmtoff1 (__main__.TimeTestCase) -- Traceback (most recent call last): File Lib/test/test_time.py, line 225, in test_tm_gmtoff1 time.strftime(%z), time.strftime(%z, time.localtime())) AssertionError: '+0200' != '+' == FAIL: test_tm_gmtoff2 (__main__.TimeTestCase) -- Traceback (most recent call last): File Lib/test/test_time.py, line 238, in test_tm_gmtoff2 time.strftime(%z, time.localtime()), +) AssertionError: '+' == '+' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue762963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/030066.html Presumably (from memory and a brief look at the reference), when if data: is evaluated, Python attempts to invoke an instance's __nonzero__ method or its __len__ method. Since the mercurial.httprepo.httpsendfile class only provides a __len__ method, the __len__ method's return value is used to determine truth. The following demonstrates this particular issue: class C: ... def __len__(self): ... return 2**35 ... c = C() if c: pass ... Traceback (most recent call last): File stdin, line 1, in module TypeError: __nonzero__ should return an int class C(object): ... def __len__(self): ... return 2**35 ... c = C() if c: pass ... Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to int Here, I could actually argue that the message mentioning __nonzero__ is obscure: there isn't such a method defined, and __len__ is the misbehaving method. Still, in the context of boolean evaluation, the OverflowError is less helpful than it could be. -- title: Inconsistent error types/messages for __len__ between old and new-style classes - Inconsistent error types/messages for __len__ (and __nonzero__) between old and new-style classes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 - not a description of the cause of the error, which is what the old-style message describes quite clearly. On the subject of whether __len__ should be able to return long integers, GvR seems to like the idea (from the related bug mentioned earlier): http://bugs.python.org/issue2690#msg70525 I'll take a closer look at the mechanisms for error reporting around this situation later, but my assertion is that the new-style message isn't as helpful as the old-style one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 a non-int, whereas new-style classes raise OverflowError. The latter is probably just as valid, but the message is a bit obscure for debugging purposes. Maybe this went away after 2.5 - if so, sorry for the noise! Here's an illustration of the problem: Python 2.5.4 (r254:67916, Nov 4 2009, 17:59:46) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 Type help, copyright, credits or license for more information. class C: ... def __len__(self): ... return 2**35 ... c = C() len(c) Traceback (most recent call last): File stdin, line 1, in module TypeError: __len__() should return an int class C(object): ... def __len__(self): ... return 2**35 ... c = C() len(c) Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to int -- components: Interpreter Core messages: 99421 nosy: pboddie severity: normal status: open title: Inconsistent error types/messages for __len__ between old and new-style classes type: behavior versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.html I concede that the different mechanisms in place for new-style classes might make it hard to have a specific error message in such a situation, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the two types and to merge them only if this is desired. See these messages for historical context around this issue: http://mail.python.org/pipermail/web-sig/2003-October/60.html http://mail.python.org/pipermail/web-sig/2003-October/000224.html http://mail.python.org/pipermail/web-sig/2003-November/000257.html Here's an old reference to the code which was changed in the cgi module: http://mail.python.org/pipermail/web-sig/2003-November/000322.html To summarise, a previous patch for this issue was never submitted because of the risk of breaking existing code. -- nosy: +pboddie ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 such a solution. It would be interesting to know what widely deployed software does use the affected parsers, though. A Google code search might be helpful. I think that the nicest compatible solution would be to have some kind of filesystem cache for the downloaded resources, but I don't recall any standard library caching solution of this nature. Things like being able to write to a known directory, perhaps using the temporary file APIs which should work even as a very unprivileged user, would be useful properties of such a solution. -- nosy: +pboddie __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2124 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
