Re: [Python-Dev] Error in buildbot link
On Sun, 24 Jun 2012 20:30:50 -0400 "Eric V. Smith" wrote: > > http://docs.python.org/devguide/buildbots.html contains a link to > http://python.org/dev/buildbot/, which redirects to > http://buildbot.python.org/index.html, which gives a 404. > > I think it should point to http://buildbot.python.org/all/waterfall, or > maybe some subset of it. Well, there used to be a written text at that place. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #15177: Added dir_fd parameter to os.fwalk().
On Mon, 25 Jun 2012 13:49:14 +0200 larry.hastings wrote: > http://hg.python.org/cpython/rev/7bebd9870c75 > changeset: 0:7bebd9870c75 > user:Larry Hastings > date:Mon Jun 25 04:49:05 2012 -0700 > summary: > Issue #15177: Added dir_fd parameter to os.fwalk(). Was it really a good idea to rush this? It's not fixing anything, just adding a new API. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #15177: Added dir_fd parameter to os.fwalk().
On Jun 25, 2012, at 02:17 PM, Antoine Pitrou wrote: >On Mon, 25 Jun 2012 13:49:14 +0200 >larry.hastings wrote: >> http://hg.python.org/cpython/rev/7bebd9870c75 >> changeset: 0:7bebd9870c75 >> user:Larry Hastings >> date:Mon Jun 25 04:49:05 2012 -0700 >> summary: >> Issue #15177: Added dir_fd parameter to os.fwalk(). > >Was it really a good idea to rush this? It's not fixing anything, just >adding a new API. Wouldn't this be considered a new feature added past the beta feature freeze? I didn't see any explicit permission from the 3.3 RM in the tracker issues for this commit. I don't read Georg's comment in msg163937 as providing that permission. Please either revert or have Georg approve the patch in the tracker. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #15177: Added dir_fd parameter to os.fwalk().
Original-Nachricht > Datum: Mon, 25 Jun 2012 10:01:19 -0400 > Von: Barry Warsaw > An: python-dev@python.org > Betreff: Re: [Python-Dev] cpython: Issue #15177: Added dir_fd parameter to > os.fwalk(). > On Jun 25, 2012, at 02:17 PM, Antoine Pitrou wrote: > > >On Mon, 25 Jun 2012 13:49:14 +0200 > >larry.hastings wrote: > >> http://hg.python.org/cpython/rev/7bebd9870c75 > >> changeset: 0:7bebd9870c75 > >> user:Larry Hastings > >> date:Mon Jun 25 04:49:05 2012 -0700 > >> summary: > >> Issue #15177: Added dir_fd parameter to os.fwalk(). > > > >Was it really a good idea to rush this? It's not fixing anything, just > >adding a new API. How do you know it was rushed? There is plenty time for testing during the beta period. > Wouldn't this be considered a new feature added past the beta feature > freeze? > I didn't see any explicit permission from the 3.3 RM in the tracker issues > for > this commit. I don't read Georg's comment in msg163937 as providing that > permission. Please either revert or have Georg approve the patch in the > tracker. Relax. It was with my permission. IMO it is quite a logical extension of fwalk using the new features supporting dir_fd -- the whole point of fwalk() is working with directory fds instead of names. cheers, Georg -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.3 feature freeze
Hi, > please consider the default branch frozen for new features as of now. > As you know, this also includes changes like large cleanups that cannot > be considered bug fixes. [...] > > I hope that we will see the branch (and the buildbots) calm down and > stabilize a bit tomorrow, so that everything is ready for Tuesday. Can bug fixes be committed as usual or should we wait? Also, when will the 3.3 branch be started and default be open again to features? Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.3 feature freeze
Am 25.06.2012 22:34, schrieb Éric Araujo: > Hi, > >> please consider the default branch frozen for new features as of now. >> As you know, this also includes changes like large cleanups that cannot >> be considered bug fixes. [...] >> >> I hope that we will see the branch (and the buildbots) calm down and >> stabilize a bit tomorrow, so that everything is ready for Tuesday. > > Can bug fixes be committed as usual or should we wait? Yes, they can be committed: I'll branch a release clone for tagging. > Also, when will > the 3.3 branch be started and default be open again to features? I think the first rc is a good time for that. Until then, it is a good thing for everyone to be able to concentrate on bugfixing. A final 3.2 bugfix release will follow soon after 3.3.0, after which 3.2 will go into security mode, so that the time with three active 3.x branches will be short. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offer of help: http://bugs.python.org/issue10910
On 24 Jun 2012, at 17:55, "Martin v. Löwis" wrote: >>> Is this even an issue for 3.x? ISTM that the C library macros aren't >>> used, anyway, so I think this entire section could go from the header >>> files. >> >> $ grep isspace >> /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/*.h >> /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#undef >> isspace >> /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#define >> isspace(c) iswspace(btowc(c)) >> >> I'm not familiar with pyport.h usage. I do see that it protects the problem >> lines with: >> #ifdef _PY_PORT_CTYPE_UTF8_ISSUE > > I think you missed my point. Python shouldn't be using isspace anymore > at all, so any work-arounds for certain BSD versions should be outdated > and can be removed entirely. > > Of course, before implementing that solution, one would have to verify > that this claim (macros not used) is indeed true. Fine so long as the bad code goes. > >> So long as that is not defined when C++ is in use no problem. > > I'm not so much concerned with compiling with C++, but care about a > potential cleanup of the headers. I hope you are not claiming that it is o.k for python to ignore c++ developers! I hope that it is rasonable to state that the pyhon api can be used from C++ without fear or the need for hacky work arounds. > >>> For 2.7, things are more difficult. >> >> This is where a fix is required. Is there going to be another 2.7 release to >> deliver a fix in? > > Yes, there will be more 2.7 bugfix releases. If a fix is too intrusive > or too hacky, it might be that the bug must stay unfixed, though. It seems that the only reason for the problem in the header is to detect an unexpected use of isspace and friends. I cannot see why you could not at a minimum remove when C++ compiler is used. I suspect C users could rightly be unset at a C api being broken after Python.h is included. Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in buildbot link
On 25.06.2012 10:57, Antoine Pitrou wrote: > On Sun, 24 Jun 2012 20:30:50 -0400 > "Eric V. Smith" wrote: >> >> http://docs.python.org/devguide/buildbots.html contains a link to >> http://python.org/dev/buildbot/, which redirects to >> http://buildbot.python.org/index.html, which gives a 404. >> >> I think it should point to http://buildbot.python.org/all/waterfall, or >> maybe some subset of it. > > Well, there used to be a written text at that place. This is now fixed; the new rewrite rule was incorrect. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
The node specified by the designator in the subject of your message
("15817") does not exist.
Subject was: "[issue15817]"
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:
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@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 7F8771CBB4
for ; Tue, 26 Jun 2012 08:50:11 +0200 (CEST)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 3WLyYb21g5zPJ4
for ; Tue, 26 Jun 2012 08:50:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1340693411; bh=MXGTWyOd852eyn+HLLV5N+r21/D3dyRf6FtHBCuUlYg=;
h=Date:Message-Id:Content-Type:MIME-Version:
Content-Transfer-Encoding:From:To:Subject;
b=j1zqdBGYKFgD7k5LANirZo3rCACM1wxD40cuazDZxto1ONgx0w1wE7a25pHbx2yy7
AKsfTYuANuh77s8HKjmW8e6uZFggjVjANTloxwpTqIg6Iid3YV8qBGlfn9cl7VkPc5
7nKKJmtsUpV921/nU5jnixFcfeBNRbMLBqphj1uk=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 26 Jun 2012 08:50:11 +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 ; Tue, 26 Jun 2012 08:50:11 +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 )
id 1SjPbH-0001gC-32
for rep...@bugs.python.org; Tue, 26 Jun 2012 08:50:11 +0200
Date: Tue, 26 Jun 2012 08:50:11 +0200
Message-Id:
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: python-dev@python.org
To: rep...@bugs.python.org
Subject: [issue15817]
TmV3IGNoYW5nZXNldCAxZmE1MGJiY2MyMWYgYnkgTGFycnkgSGFzdGluZ3MgaW4gYnJhb
