[issue9527] Add aware local time support to datetime module
James Henstridge ja...@jamesh.id.au added the comment: One problem I can see with using a fixed offset tzinfo for localtime is that it might confuse people when doing date arithmetic. For example: d = datetime.localtime() + timedelta(days=7) While it will give a correct answer as a point in time it will have the wrong time zone offset if run just before a daylight saving transition, which could be just as confusing. I'm not sure how you'd solve this without e.g. importing pytz into the standard library though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] Catching virtual subclasses in except clauses
James Henstridge ja...@jamesh.id.au added the comment: Benjamin: if you are after a use case for this feature, see https://code.djangoproject.com/ticket/15901 In Django, there are multiple database backends, each of which currently catch the adapter's DatabaseError and reraise it as Django's DatabaseError so that Django code can handle database errors in a standard way without having to care about which backend they came from. Unfortunately, this loses some information from the exception. My idea for solving that bug was to make Django's DatabaseError an ABC. By registering the various adapter's DatabaseErrors with the ABC, it would not be necessary to catch and reraise them in the backends while still preserving the ability to catch the generic errors in the core. This works fine in Python 2.x, but it was pointed out that it would cause compatibility problems when porting to Python 3.2. -- type: enhancement - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] Catching virtual subclasses in except clauses
Changes by James Henstridge ja...@jamesh.id.au: -- type: behavior - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] ABC registration of Exceptions
James Henstridge ja...@jamesh.id.au added the comment: The documentation for ABCMeta.register() says that it makes the other class a virtual subclass. That would make the ABC a virtual base class. So whether the current behaviour is correct depends on whether you consider a virtual base to count as a base. From the reasoning behind the introduction of ABCs, it certainly sounds like it should count. Also, this is a feature that works correctly in Pyton 2.7, so could trip people up who are trying to move to Python 3. -- nosy: +jamesh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7366] weakref module example relies on behaviour not guaranteed by id()
New submission from James Henstridge ja...@jamesh.id.au: The documentation for the weakref module contains an example that uses WeakValueDictionary to implement a id2obj() lookup function that doesn't store strong references to those objects. This example implicitly assumes that the id() of an object will be unique for the lifetime of the interpreter, when it is only unique for the lifetime of the object. The problem can be demonstrated like so: 1. create an object foo 2. function 1 remembers the id of this object with oid1 = remember(foo) 3. foo gets garbage collected 4. an object bar is created and happens to get the same memory location 5. function 2 remembers the id of this object with oid2 = remember(bar) 6. function 1 looks up its stored object ID with id2obj(oid1) In step 6, the object bar is returned rather than an exception being raised. As well as the example being broken, the weakref module contains the functionality a programmer would need to do this kind of thing safely: use the weakref.ref type directly. It'd be good to replace the example with a better one. -- assignee: georg.brandl components: Documentation messages: 95530 nosy: georg.brandl, jamesh severity: normal status: open title: weakref module example relies on behaviour not guaranteed by id() versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7366] weakref module example relies on behaviour not guaranteed by id()
James Henstridge ja...@jamesh.id.au added the comment: Forgot to include a link to the documentation I was talking about: http://docs.python.org/library/weakref#example This example also appears in the 2.7a0 and 3.2a0 documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7366 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5305] imaplib should support international mailbox names
James Henstridge ja...@jamesh.id.au added the comment: I'll have a go at implementing the algorithm. It looks like the modifications to UTF-7 are large enough that you can't do a search and replace on the output of the existing UTF-7 codec, so it'll probably require new code. Would String2Mailbox and Mailbox2String utility functions be appropriate here? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5305] imaplib should support international mailbox names
New submission from James Henstridge ja...@jamesh.id.au: The IMAP4rev1 specification allows for non-ASCII mailbox names using a modified UTF-7 encoding (section 5.1.3 of RFC 2060 or 3501). However, the imaplib routines taking a mailbox name just pass the string straight through without any encoding. It would be useful if Python provided an encoder/decoder for the modified UTF-7 encoding, and optionally if imaplib would perform the encoding and decoding at the appropriate points. -- components: Library (Lib) messages: 82408 nosy: jamesh severity: normal status: open title: imaplib should support international mailbox names versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)
New submission from James Henstridge ja...@jamesh.id.au: The datetime module does not support time zones whose offset from UTC is not an integer number of minutes. The Olson time zone database (used by most UNIX systems and Mac OS X) has a number of time zones with historic offsets that use second resolution (from before those locations switched to a rounded offset from GMT). If you are working purely with the Python date time module, you can round these offsets to whole numbers of minutes and get consistent results (this is what the pytz module does), there are problems if you want to interact with other programs using the Olson database. As an example, PostgreSQL can return dates with sub-minute UTC offsets and it would be nice to be able to represent them exactly. The documentation doesn't explain why offsets need to be a whole number of minutes, and the interface (returning timedeltas) doesn't look like it'd need changing to support second offsets. I wouldn't expect any more complexity in the code to support them either. -- components: Extension Modules messages: 82299 nosy: jamesh severity: normal status: open title: tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28) versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
James Henstridge ja...@jamesh.id.au added the comment: Attached is an updated version of the patch against trunk (2.7). It simply fixes the conflicts that have occurred since the previous patch. Added file: http://bugs.python.org/file12935/disable-pymalloc-on-valgrind-py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2422 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2604] doctest.DocTestCase fails when run repeatedly
James Henstridge [EMAIL PROTECTED] added the comment: Is repeating a test with the same TestCase instance ever safe? It'd be better to create a new instance and run that. If any of the variables in test.globs are changed by the test (e.g. appending to a list), then rerunning the test will not necessarily give the same result. While the zope change allows tests that have immutable globals or don't change their globals to function, it also lets other tests almost work, and could lead to new bugs that are difficult to track down. -- nosy: +jamesh __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2604 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2604] doctest.DocTestCase fails when run repeatedly
James Henstridge [EMAIL PROTECTED] added the comment:
If I create a test case with a command like:
test = DocFileSuite('foo.txt', globs={'somelist': [42]})
The doctest isn't doing anything wrong if it modifies somelist.
Furthermore, Glyph has said he thinks the current --until-failure
behaviour in trial is a mistake: http://glyf.livejournal.com/72505.html
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2604
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
James Henstridge [EMAIL PROTECTED] added the comment: There are probably a few other performance optimisations that would be good to turn off when running under valgrind. A big one is the tuple cache: if there are tuple reference counting issues, they won't necessarily be seen by valgrind if the tuple is kept and reused rather than being freed. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2422 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
James Henstridge [EMAIL PROTECTED] added the comment: An updated version of the patch. The previous ones were missing the valgrind check, resulting in the pymalloc code paths being executed (which in turn cause unintialised read warnings from valgrind). Added file: http://bugs.python.org/file9872/disable-pymalloc-on-valgrind-py26.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2422 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
James Henstridge [EMAIL PROTECTED] added the comment: Here's the updated version of my patch (the obmalloc.c bits applied without conflicts to the newer source tree). The configure changes are a bit different to Lauro's ones, in that they check for the existence of the valgrind/valgrind.h header if Valgrind support was requested. Added file: http://bugs.python.org/file9837/disable-pymalloc-on-valgrind-py26.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2422 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
New submission from James Henstridge [EMAIL PROTECTED]: When I want to use valgrind to check for leaks in a Python program (or test suite), I generally want pymalloc disabled. When not running valgrind I generally want it enabled. Attached is a patch that automatically bypasses the pymalloc code when running under valgrind but leaves it enabled overwise. It is controlled by a WITH_VALGRIND #define, but I haven't updated the configure script to allow turning it on. I also haven't done much in the way of profiling to see what the overhead is when not running under valgrind. -- components: Interpreter Core files: disable-pymalloc-on-valgrind.patch keywords: patch messages: 64052 nosy: jamesh severity: normal status: open title: Automatically disable pymalloc when running under valgrind type: feature request versions: Python 2.5 Added file: http://bugs.python.org/file9765/disable-pymalloc-on-valgrind.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2422 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
Changes by James Henstridge [EMAIL PROTECTED]: Added file: http://bugs.python.org/file9781/disable-pymalloc-on-valgrind-v3.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2422 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
Changes by James Henstridge [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9780/disable-pymalloc-on-valgrind-v2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2422 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1339] smtplib starttls() should ehlo() if it needs to
James Henstridge added the comment: From RFC 2487 section 5.2: The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation. So the starttls() method should probably also be clearing helo_resp and ehlo_resp (and maybe anything else discovered by ehlo()). There are servers in the wild that will (a) refuse to talk to you unless you issue another EHLO after TLS is negotiated and (b) offer a different set of ESMTP features (such as only supporting SMTP AUTH after TLS). This patch isn't enough to talk to such servers. -- nosy: +jamesh __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1339 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
