Mailman 3 November 2011 - Python-Dev

Failed issue tracker submission
by Python tracker Nov. 7, 2011

Nov. 7, 2011

The node specified by the designator in the subject of your message ("13661") does not exist. Subject was: "[issue13661] [status=closed; resolution=fixed; stage=committed/rejected]" Mail Gateway Help ================= Incoming messages are examined for multiple parts: . In a multipart/mixed message or part, each subpart is extracted and examined. The text/plain subparts are assembled to form the textual body of the message, to be stored in the file associated with a "msg" class node. Any parts of other types are each stored in separate files and given "file" class nodes that are linked to the "msg" node. . In a multipart/alternative message or part, we look for a text/plain subpart and ignore the other parts. . A message/rfc822 is treated similar tomultipart/mixed (except for special handling of the first text part) if unpack_rfc822 is set in the mailgw config section. Summary ------- The "summary" property on message nodes is taken from the first non-quoting section in the message body. The message body is divided into sections by blank lines. Sections where the second and all subsequent lines begin with a ">" or "|" character are considered "quoting sections". The first line of the first non-quoting section becomes the summary of the message. Addresses --------- All of the addresses in the To: and Cc: headers of the incoming message are looked up among the user nodes, and the corresponding users are placed in the "recipients" property on the new "msg" node. The address in the From: header similarly determines the "author" property of the new "msg" node. The default handling for addresses that don't have corresponding users is to create new users with no passwords and a username equal to the address. (The web interface does not permit logins for users with no passwords.) If we prefer to reject mail from outside sources, we can simply register an auditor on the "user" class that prevents the creation of user nodes with no passwords. Actions ------- The subject line of the incoming message is examined to determine whether the message is an attempt to create a new item or to discuss an existing item. A designator enclosed in square brackets is sought as the first thing on the subject line (after skipping any "Fwd:" or "Re:" prefixes). If an item designator (class name and id number) is found there, the newly created "msg" node is added to the "messages" property for that item, and any new "file" nodes are added to the "files" property for the item. If just an item class name is found there, we attempt to create a new item of that class with its "messages" property initialized to contain the new "msg" node and its "files" property initialized to contain any new "file" nodes. Triggers -------- Both cases may trigger detectors (in the first case we are calling the set() method to add the message to the item's spool; in the second case we are calling the create() method to create a new node). If an auditor raises an exception, the original message is bounced back to the sender with the explanatory message given in the exception. $Id: mailgw.py,v 1.196 2008-07-23 03:04:44 richard Exp $ Return-Path: <python-dev(a)python.org> X-Original-To: report(a)bugs.python.org Delivered-To: roundup+tracker(a)psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 2EFFC1DE47 for <report(a)bugs.python.org>; Mon, 7 Nov 2011 09:55:13 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3ScSJm5CFjzNHh for <report(a)bugs.python.org>; Mon, 7 Nov 2011 09:55:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1320656104; bh=cyzeMXQr1LFbdsO9tordSV8pQdV5MwemLO4/gJ4vIY0=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=jc4GjbMIfB4iVA2crVNpOAuf8gWkNAWpABvzog5HDVxOrgwEYwPLu+yg/c02Ix5zf P+0/l1dcenWA/8pFCOthL4UvWmykT+XVrUf6FtByHAP0JijJR9ItrOM5NKD6SBN6e5 5vsORTztxsUksIq48QwMAQsURD408JBkbkM0b7bM= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 07 Nov 2011 09:55:04 +0100 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for <report(a)bugs.python.org>; Mon, 7 Nov 2011 09:55:04 +0100 (CET) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from <python-dev(a)python.org>) id 1RNKys-0002nh-Es for report(a)bugs.python.org; Mon, 07 Nov 2011 09:55:02 +0100 Date: Mon, 07 Nov 2011 09:55:02 +0100 Message-Id: <E1RNKys-0002nh-Es(a)dinsdale.python.org> Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: python-dev(a)python.org To: report(a)bugs.python.org Subject: [issue13661] [status=closed; resolution=fixed; stage=committed/rejected] TmV3IGNoYW5nZXNldCA1ZjNiNzUyOGIxNDQgYnkgVmluYXkgU2FqaXAgaW4gYnJhbmNoICcyLjcn OgpDbG9zZXMgIzEzNjYxOiBDaGVjayBhZGRlZCBmb3IgdHlwZSBvZiBsb2dnZXIgbmFtZS4KaHR0 cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvNWYzYjc1MjhiMTQ0CgoKTmV3IGNoYW5nZXNl dCBhM2JhOTA1NDQ3YmEgYnkgVmluYXkgU2FqaXAgaW4gYnJhbmNoICczLjInOgpDbG9zZXMgIzEz NjYxOiBDaGVjayBhZGRlZCBmb3IgdHlwZSBvZiBsb2dnZXIgbmFtZS4KaHR0cDovL2hnLnB5dGhv bi5vcmcvY3B5dGhvbi9yZXYvYTNiYTkwNTQ0N2JhCg==

1 0

PyDict_Get/SetItem and dict subclasses
by Victor Stinner Nov. 6, 2011

Nov. 6, 2011

Hi, PyDict_GetItem() and PyDict_SetItem() don't call __getitem__ and __setitem__ for dict subclasses. Is there a reason for that? I found this surprising behaviour when I replaced a dict by a custom dict checking the key type on set. But my __setitem__ was not called because the function using the dict was implemented in C (and I didn't know that ;-)). Victor

6 5

PEP 382 specification and implementation complete
by "Martin v. Löwis" Nov. 6, 2011

Nov. 6, 2011

I had announced this to import-sig already; now python-dev. I have now written an implementation of PEP 382, and fixed some details of the PEP in the process. The implementation is available at http://hg.python.org/features/pep-382-2/ With this PEP, a Python package P can consist of either a P/__init__.py directory and module, or multiple P.pyp directories, or both. Using a directory suffix resulted from the following requirements/observations: - people apparently prefer an approach where a directory has to be declared as a Python package (several people commented this after my PyConDE talk, expressing dislike of how Java packages are "unflagged" directories) - people also commented that any declaration should indicate that this is about Python, hence the choice of .pyp as the directory suffix. - in choosing between a file marker inside of the directory (e.g. zope-interfaces.pyp) and a directory suffix, the directory suffix wins for simplicity reasons. A file marker would have to have a name which wouldn't matter except that it needs to be unique - which is a confusing requirement that people likely would fail to meet. In the new form, the PEP was much easier to implement than in the first version (plus I understand import.c better now). This implementation now features .pyp directories, zipimporter support, documentation and test cases. As the next step, I'd like to advance this to ask for pronouncement. Regards, Martin

3 4

Re: [Python-Dev] [Python-checkins] cpython: Fix #13327. Remove the need for an explicit None as the second argument to
by Benjamin Peterson Nov. 6, 2011

Nov. 6, 2011

2011/11/6 brian.curtin <python-checkins(a)python.org>: > - > - if (!PyArg_ParseTuple(args, "O&O:utime", > + PyObject* arg = NULL; You could set arg = Py_None here. > + > + if (!PyArg_ParseTuple(args, "O&|O:utime", > PyUnicode_FSConverter, &opath, &arg)) > return NULL; > path = PyBytes_AsString(opath); > - if (arg == Py_None) { > + if (!arg || (arg == Py_None)) { And then not have to change this. -- Regards, Benjamin

2 1

Why does _PyUnicode_FromId return a new reference?
by Antoine Pitrou Nov. 6, 2011

Nov. 6, 2011

Given it returns an eternal object, and it's almost always used temporarily (for attribute lookup, string joining, etc.), it would seem more practical for it to return a borrowed reference. Regards Antoine.

2 2

genious hack in python
by Martin Goudreau Nov. 6, 2011

Nov. 6, 2011

Hello Dev Teem, Guido told me to send you this idea... Improving productivity is one of my Strength. Please check a very small module i'v made for improving the debugger traceback. See the pybettererror.py on sourceforge: http://pybettererror.sourceforge.net/projet.html It's hard to find something to complain about in python. This one was a too good idea to keep for myself. Thanks Martin Goudreau from Montreal

2 2

Code cleanups in stable branches?
by Éric Araujo Nov. 4, 2011

Nov. 4, 2011

Hi, > http://hg.python.org/cpython/rev/72de2ac8bb4f > branch: 2.7 > user: Petri Lehtinen <petri(a)digip.org> > date: Sun Oct 30 13:55:02 2011 +0200 > summary: > Avoid unnecessary recursive function calls (closes #10519) > http://hg.python.org/cpython/rev/0694ebb5db99 > branch: 2.7 > user: Jesus Cea <jcea(a)jcea.es> > date: Mon Oct 31 16:02:12 2011 +0100 > summary: > Closes #13283: removal of two unused variable in locale.py I thought that patches that clean up code but don’t fix actual bugs were not done in stable branches. Has this changed? (The first commit quoted above may be a performance fix, which would be okay IIRC.) Regards

5 6

Unicode exception indexing
by martin＠v.loewis.de Nov. 4, 2011

Nov. 4, 2011

There is a backwards compatibility issue with PEP 393 and Unicode exceptions: the start and end indices: are they Py_UNICODE indices, or code point indices? On the one hand, these indices are used in formatting error messages such as "codec can't encode character \u%04x in position %d", suggesting they are regular indices into the string (counting code points). On the other hand, they are used by error handlers to lookup the character, and existing error handlers (including the ones we have now) use PyUnicode_AsUnicode to find the character. This suggests that the indices should be Py_UNICODE indices, for compatibility (and they currently do work in this way). The indices can only be different if the string is an UCS-4 string, and Py_UNICODE is a two-byte type (i.e. on Windows). So what should it be? As a compromise, it would be possible to convert between these indices, by counting the non-BMP characters that precede the index if the indices might differ. That would be expensive to compute, but provide backwards compatibility to the C API. It's less clear what backwards compatibility to Python code would require - most likely, people would use the indices for slicing operations (rather than performing an UTF-16 conversion and performing indexing on that). Regards, Martin

8 13

Re: [Python-Dev] [Python-checkins] cpython (2.7): Inline the advisory text on how to use the shelve module.
by Eric V. Smith Nov. 4, 2011

Nov. 4, 2011

On 11/4/2011 4:08 PM, raymond.hettinger wrote: > - .. note:: > + Like file objects, shelve objects should closed explicitly to assure > + that the peristent data is flushed to disk. Missing "be" there, I think: "should be closed". Eric.

2 2

Re: [Python-Dev] [Python-checkins] cpython: Port code page codec to Unicode API.
by Victor Stinner Nov. 4, 2011

Nov. 4, 2011

Le vendredi 4 novembre 2011 18:23:26, martin.v.loewis a écrit : > http://hg.python.org/cpython/rev/9191f804d376 > changeset: 73353:9191f804d376 > parent: 73351:2bec7c452b39 > user: Martin v. Löwis <martin(a)v.loewis.de> > date: Fri Nov 04 18:23:06 2011 +0100 > summary: > Port code page codec to Unicode API. Oh please, try to avoid introducing tabs when a file uses spaces. All C files are supposed to use an indentation of 4 spaces. Victor

1 0