I have decided to add two new buildslaves to the stable buildbots fleet:
- Łukasz Langa's AMD64 OS Lion buildbot (using clang as compiler)
- Jeremy Kloth's AMD64 Windows7 buildbot (our first 64-bit Windows
They bring the number of stable buildbots to twelve: 4 Windows, 5
Linux and 3 other Unices:
There was a problem with the message you sent:
This issue can't be closed until issue <a href="http://bugs.python.org/issue15031">15031</a> is closed.
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.
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.
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.
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"
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 $
Received: from mail.python.org (mail.python.org [220.127.116.11])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 5E7D11CC7C
for <report(a)bugs.python.org>; Mon, 2 Jul 2012 20:36:31 +0200 (CEST)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 3WQxxp54vszPJ6
for <report(a)bugs.python.org>; Mon, 2 Jul 2012 20:36:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 02 Jul 2012 20:36:30 +0200
Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [18.104.22.168])
by mail.python.org (Postfix) with ESMTP
for <report(a)bugs.python.org>; Mon, 2 Jul 2012 20:36:30 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Subject: [issue15030] [status=closed; resolution=fixed;
Date: Mon, 2 Jul 2012 20:36:30 +0200 (CEST)
Stefan Behnel wrote:
> Paul Boddie, 01.07.2012 02:22:
> > Is there any reason why the compiler-sig mailing list wasn't chosen as a
> > venue
> Even I didn't know that this list even existed. And looking at the archives
> now, it's hard to see any relevant discussion in all the spam it received
> until it apparently died away in (almost) silence a couple of years ago.
Yes, although the mailing lists for special interest groups are advertised on
python.org, there is no longer the focus on steering discussion to those
lists. And I see that the compiler SIG is "retired", as is the related types
I seem to remember various procedures about SIGs and their retirement, but I
don't really recall much discussion of such things recently. Still, the
compiler SIG matches the scope of the Google group pretty well:
There's even a link to discussion of some tools you may be familiar with.
> > It's obviously your choice where you host discussions and who you invite,
> > and I know that the special interest group mailing lists aren't exactly
> > well advertised these days
> True, but many (most?) of them are simply not very well frequented, which
> reduces the interest in joining them even further. Both SIG mailing lists
> that I read only receive a mail every so many months, often enough without
> any reply. And almost all of these mails deal with questions that would
> better be discussed on python-list to leverage the substantially higher
> number of eyeballs there.
Special interest group lists were always meant to be used as focused channels
of communication where people are actively trying to get stuff done. The
unfortunate thing is that they aren't as well known as they were. Another
unfortunate thing is that getting stuff done of mutual benefit is frequently
something that takes second place to whatever other motivations and goals
people have, for whatever reason, good or bad. Thus, traffic drops away as
people either do other things entirely or instead promote any related work in
other channels instead.
> I think that's the basic problem: as long as more experts are lurking on
> python-list than on the dedicated SIG-ML, it's better not to use the SIG-ML
> for discussions but to go to python-list (or maybe python-ideas or
> python-dev) straight away.
I think we really have to sort out what python-dev is for, because currently
there's a tendency to target the list when any kind of "expert" discussion is
required, but there are a number of people who would rather see only
CPython-related discussion here.
Another matter is that static analysis of Python is a topic that frequently
hits the end of the road when one cannot, by definition, analyze Python in
its most dynamic form, and when people refuse to accept that such analysis
has anything to do with Python in its most pure, undiluted (and most
But as I wrote, I still intend to follow the newly created group and see what
people have to say.
hg.python.org has just been migrated to a new (virtual) machine hosted
by OSU OSL (*). Until the domain name fully propagates, you won't be
able to push or pull from the repositories using the ssh protocol.
If you notice other issues, don't hesitate to mention them.
Edward K. Ream wrote:
> Hello all,
> GvR has asked me to announce the python-static-type-checking google
> group http://groups.google.com/group/python-static-type-checking to
> Consider it announced. Anyone from python-dev who likes may become a
Is there any reason why the compiler-sig mailing list wasn't chosen as a venue
for such discussions? I know it has "compiler" in the title, but the mandate
overlaps significantly with what you intend to discuss.
It's obviously your choice where you host discussions and who you invite, and
I know that the special interest group mailing lists aren't exactly well
advertised these days, what with the lack of agility around updating the Web
content that advertises such things (or the lack of visibility of the Wiki
content), but I feel that you might have a more productive discussion if you
don't insist on Google Groups membership and also allow a wider selection of
Please consider this as friendly advice: I too would like to see progress in
the area concerned.
I think these patches are premature (they break compilation on OS X,
and they break ctypes configure on my Linux box). Furthermore, they
were committed post-beta, which means they should probably have waited
for after the 3.3 release. So I propose for these commits to be
(to be clear, I'm talking about all configure / Makefile / setup.py /
libffi changes since and including
On 01.07.2012 01:58, raymond.hettinger wrote:
> changeset: 77899:da4dd603030b
> user: Raymond Hettinger <python(a)rcn.com>
> date: Sat Jun 30 16:58:06 2012 -0700
> Add syntax highlighter tool
> Tools/scripts/pycolorize.py | 109 ++++++++++++++++++++++++
> 1 files changed, 109 insertions(+), 0 deletions(-)
Uh, this looks quite a lot like a new feature...
Since it's in Tools, I'm not going to veto it, just as with the
improvements to the gdb helper, but it would have been nice to
at least *ask*...