Mailman 3 May 2012 - Python-Dev

Does trunk still support any compilers that *don't* allow declaring variables after code?
by Larry Hastings May 7, 2012

May 7, 2012

Right now the CPython trunk religiously declares all variables at the tops of scopes, before any code, because this is all C89 permits. Back in the 90s all the C compilers took a page out of the C++ playbook and independently, but nearly without exception, extended the language to allow you declaring new variables after code statements. This became an official part of the language with C99 back in 1999. It's now 2012. As I step out of my flying car onto the moving walkway that will … [View More]

10 10

Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice
by Barry Warsaw May 7, 2012

May 7, 2012

Thanks for doing this update Nick. I have just a few comments. On May 05, 2012, at 02:57 PM, nick.coghlan wrote: >+Developers with commit privileges for the `PEP repository`_ may claim >+PEP numbers directly by creating and committing a new PEP. When doing so, >+the developer must handle the tasks that would normally be taken care of by >+the PEP editors (see `PEP Editor Responsibilities & Workflow`_). While I certainly don't mind (in fact, prefer) those with commit … [View More]privileges to just go ahead and commit their PEP to the repo, I'd like for there to be *some* communication with the PEP editors first. E.g. sanity checks on the basic format or idea (was this discussed on python-ideas first?), or reservation of PEP numbers. When you do contact the PEP editors, please also specify whether you have commit privileges or not. It's too hard to remember or know who has those rights, and too much hassle to look them up. ;) OTOH, I'm also happy to adopt an EAFP style rather than LBYL, so that the PEP editors can re-assign numbers or whatever after the fact. We've done this in a few cases, and it's never been that much of a problem. Still, core developers needn't block (for too long) on the PEP editors. >+The final authority for PEP approval is the BDFL. However, whenever a new >+PEP is put forward, any core developer that believes they are suitably >+experienced to make the final decision on that PEP may offer to serve as >+the "PEP czar" for that PEP. If their self-nomination is accepted by the >+other core developers and the BDFL, then they will have the authority to >+approve (or reject) that PEP. This process happens most frequently with PEPs >+where the BDFL has granted in principle approval for *something* to be done, >+but there are details that need to be worked out before the PEP can be >+accepted. I'd reword this to something like the following: The final authority for the PEP approval is the BDFL. However, the BDFL may delegate the final approval authority to a "PEP czar" for that PEP. This happens most frequently with PEPs where the BDFL has granted approval in principle for *something* to be done, and in agreement with the general proposals of the PEP, but there are details that need to be worked out before the final PEP can be approved. When an `PEP-Czar` header must be added to the PEP to record this delegation. The format of this header is the same as the `Author` header. This leave out the whole self-nomination text, which I think isn't very relevant to the official addition of the czar role (sadly, no clever bacronym has come to mind, and BDFOP hasn't really taken off ;). >+* Run ``./genpepindex.py`` and ``./pep2html.py <PEP Number>`` to ensure they >+ are generated without errors. If either triggers errors, then the web site >+ will not be updated to reflect the PEP changes. Or just run "make" on systems that have that handy convenience. :) Cheers, -Barry (Nick, if you agree with these changes, please just go ahead and make them.) [View Less]

3 5

Recording BDFL delegates for PEPs
by Nick Coghlan May 7, 2012

May 7, 2012

At Barry's suggestion (following my PEP 1 updates), I've also updated the PEP 0 generation machinery to handle an explicit "BDFL-Delegate" field. You can see an example here with PEP 3151: http://www.python.org/dev/peps/pep-3151/ I also updated the 3 PEPs that are on my plate (405, 415 and 3144). If there's anyone else that got tapped as a PEP czar, please update the corresponding PEPs in the repo. For the moment, I suggest leaving your email address out of this field. The email obfuscation … [View More]

5 5

Re: [Python-Dev] cpython: Make AcquirerProxy.acquire() support timeout argument
by Antoine Pitrou May 6, 2012

May 6, 2012

On Sun, 06 May 2012 17:56:55 +0200 richard.oudkerk <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/b4a1d9287780 > changeset: 76800:b4a1d9287780 > user: Richard Oudkerk <shibturn(a)gmail.com> > date: Sun May 06 16:45:02 2012 +0100 > summary: > Make AcquirerProxy.acquire() support timeout argument Should it have a Misc/NEWS entry? (and a doc addition perhaps?) Regards Antoine.

2 2

Failed issue tracker submission
by Python tracker May 6, 2012

May 6, 2012

The node specified by the designator in the subject of your message ("14965") does not exist. Subject was: "[issue14965]" 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 … [View More]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 5B02E1CB4A for <report(a)bugs.python.org>; Sun, 6 May 2012 18:35:44 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3Vlsym0qbgzM1L for <report(a)bugs.python.org>; Sun, 6 May 2012 18:35:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1336322144; bh=Mpmd9a48weoSfYj5dd0SkAaR6Nf9eu6lSG6CDGbSb1k=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=yESPEjvi+ZH3aflpJVezllCl9rV7jAt75IuTHe8dRUjq/yetx2Lp45W5s5kVVY2bH oKtFGyN1RrRN2NOtjhj+b4G5WnZ2rSxCJTtGJ4ERXaNMVCXRkvbJ/aa/cdIE+R1mC/ ZYUuEZTBWQ0moIFEX+DJAXZ/23ELCDE0Xl+ZIUdE= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 06 May 2012 18:35:44 +0200 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>; Sun, 6 May 2012 18:35:44 +0200 (CEST) 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 1SR4Qx-0002Si-Tp for report(a)bugs.python.org; Sun, 06 May 2012 18:35:43 +0200 Date: Sun, 06 May 2012 18:35:43 +0200 Message-Id: <E1SR4Qx-0002Si-Tp(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: [issue14965] TmV3IGNoYW5nZXNldCBjODA1NzYzMDM4OTIgYnkgTWFyayBEaWNraW5zb24gaW4gYnJhbmNoICcz LjInOgpJc3N1ZSAjMTQ5NjU6IEZpeCBtaXNzaW5nIHN1cHBvcnQgZm9yIHN0YXJyZWQgYXNzaWdu bWVudHMgaW4gVG9vbHMvcGFyc2VyL3VucGFyc2UucHkuCmh0dHA6Ly9oZy5weXRob24ub3JnL2Nw eXRob24vcmV2L2M4MDU3NjMwMzg5MgoKCk5ldyBjaGFuZ2VzZXQgODllOTI4MDQ4OTAzIGJ5IE1h cmsgRGlja2luc29uIGluIGJyYW5jaCAnZGVmYXVsdCc6Cklzc3VlICMxNDk2NTogIEJyaW5nIFRv b2xzL3BhcnNlci91bnBhcnNlLnB5IHVwIHRvIGRhdGUgd2l0aCB0aGUgUHl0aG9uIDMuMy4gR3Jh bW1hci4KaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvODllOTI4MDQ4OTAzCg== [View Less]

1 0

Re: [Python-Dev] [Python-checkins] cpython: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.)
by Stefan Krah May 5, 2012

May 5, 2012

larry.hastings <python-checkins(a)python.org> wrote: > Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) > > + * De-vararg'd PyArg_ParseTupleAndKeywords() This looks like an accidental commit. Is there an issue number for the varargs changes (just out of interest)? Stefan Krah

2 1

Re: [Python-Dev] [Python-checkins] cpython: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.)
by Benjamin Peterson May 5, 2012

May 5, 2012

2012/5/5 larry.hastings <python-checkins(a)python.org>: > http://hg.python.org/cpython/rev/709850f1ec67 > changeset: 76777:709850f1ec67 > user: Larry Hastings <larry(a)hastings.org> > date: Sat May 05 17:39:09 2012 -0700 > summary: > Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) > > files: > Modules/posixmodule.c | 372 ++++++++++++++++++++++++++… [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython: Issue #14705: Add 'p' format character to PyArg_ParseTuple* for bool support.
by Benjamin Peterson May 5, 2012

May 5, 2012

2012/5/5 larry.hastings <python-checkins(a)python.org>: > http://hg.python.org/cpython/rev/bc6d28e726d8 > changeset: 76776:bc6d28e726d8 > user: Larry Hastings <larry(a)hastings.org> > date: Sat May 05 16:54:29 2012 -0700 > summary: > Issue #14705: Add 'p' format character to PyArg_ParseTuple* for bool support. > > files: > Doc/c-api/arg.rst | 9 ++++++… [View More]

1 0

Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
by Edward C. Jones May 5, 2012

May 5, 2012

dpkg-architecture -qDEB_HOST_MULTIARCH gives x86_64-linux-gnu Installing dpkg-dev fixed the problem. Now both 3.3a3 and a developmental "clone" work. There is already a Debian package for 3.3 alpha3. See http://packages.debian.org/source/experimental/python3.3 A large diff for Debian Python is available at this url. The following should be installed before compiling python3. This list may be incomplete. This list may include unnecessary packages. dpkg-dev sharutils libreadline6-dev … [View More]

1 0

PEP 1 updated to reflect current practices
by Nick Coghlan May 5, 2012

May 5, 2012

I just pushed an update to PEP 1 to give additional guidance to core developers that are directly updating a PEP in Mercurial, to account for the automatic generation of PEP 0 and to mention the "PEP czar" role. Updated PEP: http://www.python.org/dev/peps/pep-0001/ Changes: http://hg.python.org/peps/rev/bdbbd3ce97d9 Any additional feedback here (I'll leave the issue open for a while): http://bugs.python.org/issue14703 (although remember that the bar for this PEP is "useful and fairly … [View More]

1 0