Re: [Python-Dev] peps: Update PEP 1 to better reflect current practice
On Sun, 6 May 2012 15:08:52 +1000 Nick Coghlan wrote: > > Agreed we should have a new header field to record the BDFL delegate, > but I think I'll go with BDFL-Delegate rather than PEP-Czar. +1 for overthrowing czars! Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recording BDFL delegates for PEPs
On Sun, 6 May 2012 16:45:32 +1000 Nick Coghlan wrote: > > For the moment, I suggest leaving your email address out of this > field. The email obfuscation is applied on a field-by-field basis, and > the formatter for reStructuredText PEPs actually lives in the docutils > upstream rather than being included directly in the PEPs repo the way > the plaintext formatter is. I have to ask - is email obfuscation still useful these days? I would have thought most people protect from spam by using spam filters, not by trying to conceal their addresses. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update PEP 1 to better reflect current practice
On Sun, May 6, 2012 at 5:29 PM, Antoine Pitrou wrote: > On Sun, 6 May 2012 15:08:52 +1000 > Nick Coghlan wrote: >> >> Agreed we should have a new header field to record the BDFL delegate, >> but I think I'll go with BDFL-Delegate rather than PEP-Czar. > > +1 for overthrowing czars! I expect PEP czar will stick as the nickname (that's why I still mention it in PEP 1), but I definitely prefer having something a bit more self explanatory as the official designation. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recording BDFL delegates for PEPs
On Sun, May 6, 2012 at 5:31 PM, Antoine Pitrou wrote: > On Sun, 6 May 2012 16:45:32 +1000 > Nick Coghlan wrote: >> >> For the moment, I suggest leaving your email address out of this >> field. The email obfuscation is applied on a field-by-field basis, and >> the formatter for reStructuredText PEPs actually lives in the docutils >> upstream rather than being included directly in the PEPs repo the way >> the plaintext formatter is. > > I have to ask - is email obfuscation still useful these days? I would > have thought most people protect from spam by using spam filters, not > by trying to conceal their addresses. I think it's one of those things where people *like* seeing it, regardless of how effective it is in practice. The delegate field isn't actually parsed at all, so people are free to include their email address if they choose to - doing so won't be *necessary* until we get an actual name collision amongst the core developers. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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: Make AcquirerProxy.acquire() support timeout argument
On Sun, 06 May 2012 17:56:55 +0200 richard.oudkerk wrote: > http://hg.python.org/cpython/rev/b4a1d9287780 > changeset: 76800:b4a1d9287780 > user:Richard Oudkerk > 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. ___ Python-Dev mailing list [email protected] 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
("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 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: [email protected]
Delivered-To: [email protected]
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 5B02E1CB4A
for ; 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 ; 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 ; 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 )
id 1SR4Qx-0002Si-Tp
for [email protected]; Sun, 06 May 2012 18:35:43 +0200
Date: Sun, 06 May 2012 18:35:43 +0200
Message-Id:
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: [email protected]
To: [email protected]
Subject: [issue14965]
TmV3IGNoYW5nZXNldCBjODA1NzYzMDM4OTIgYnkgTWFyayBEaWNraW5zb24gaW4gYnJhb
Re: [Python-Dev] cpython: Make AcquirerProxy.acquire() support timeout argument
On 06/05/2012 5:07pm, Antoine Pitrou wrote: On Sun, 06 May 2012 17:56:55 +0200 summary: Make AcquirerProxy.acquire() support timeout argument Should it have a Misc/NEWS entry? (and a doc addition perhaps?) Since proxies for locks/semaphores are supposed to work the same way as the proxied object from threading, one could argue that the lack of support in 3.2 was a bug. I notice now that multiprocessing.*.acquire() and threading.*.wait() treat negative timeouts as zero timeouts. On the other hand, threading.*.acquire() treat negative timeouts as infinite. Maybe these inconsistencies should be documented or eliminated? As currently implemented AcquirerProxy.acquire() treats negative timeouts as infinite. Cheers Richard ___ Python-Dev mailing list [email protected] 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: Make AcquirerProxy.acquire() support timeout argument
On Sun, 06 May 2012 18:58:10 +0100 shibturn wrote: > On 06/05/2012 5:07pm, Antoine Pitrou wrote: > > On Sun, 06 May 2012 17:56:55 +0200 > >> summary: > >>Make AcquirerProxy.acquire() support timeout argument > > > > Should it have a Misc/NEWS entry? (and a doc addition perhaps?) > > Since proxies for locks/semaphores are supposed to work the same way as > the proxied object from threading, one could argue that the lack of > support in 3.2 was a bug. Ok; if it's a bug it should have a NEWS entry, though. > I notice now that multiprocessing.*.acquire() and threading.*.wait() > treat negative timeouts as zero timeouts. On the other hand, > threading.*.acquire() treat negative timeouts as infinite. > > Maybe these inconsistencies should be documented or eliminated? I don't know. Ideally both would have raised ValueError on negative timeouts, but it's probably too late :-) cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
On 05/05/2012 02:38 AM, Vinay Sajip wrote: Nick Coghlan gmail.com> writes: Personally, I expect that "always update your virtual environment binaries after updating the system Python to a new point release" will itself become a recommended practice when using virtual environments. Of course, the venv update tool will need to only update environments which were set up with the particular version of Python which was updated. ISTM pyvenv.cfg will need to have a version=X.Y.Z line in it, which is added during venv creation. That information will be used by the tool to only update specific environments. I don't think the added "version" key in pyvenv.cfg is needed; the "home" key provides enough information to know whether the virtualenv was created by the particular Python that was upgraded. The "version" key could in theory be useful to know whether a particular venv created by that Python has or has not yet been upgraded to match, but since the upgrade is trivial and idempotent I don't think that is important. Carl ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
On 05/05/2012 04:40 AM, Antoine Pitrou wrote: On Fri, 04 May 2012 14:49:03 -0600 Carl Meyer wrote: 3) Symlink the interpreter rather than copying. I include this here for the sake of completeness, but it's already been rejected due to significant problems on older Windows' and OS X. Perhaps symlinking could be used at least on symlinks-friendly OSes? I expect older Windows to disappear one day :-) So the only left outlier would be OS X. It certainly could - at one point the reference implementation did exactly this. I understand though that even on newer Windows' there are administrator-privilege issues with symlinks, and I don't know that there's any prospect of the OS X stub executable going away, so I think if we did this we should assume that we're accepting a more-or-less permanent cross-platform difference in the default behavior of venvs. Maybe that's ok; it would mean that for Linux users there'd be no need to run any venv-upgrade script at all when Python is updated, which is certainly a plus. At one point it was argued that we shouldn't symlink by default because users expect venvs to be isolated and not upgraded implicitly. I think this discussion reveals that that's a false argument, since the stdlib will be upgraded implicitly regardless, and that's just as likely to break something as an interpreter update (and more likely than upgrading them in sync). IOW, if you want real full isolation from a system Python, you build your own Python, you don't use pyvenv. Carl ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
On 05/05/2012 12:41 AM, Nick Coghlan wrote: On Sat, May 5, 2012 at 6:49 AM, Carl Meyer wrote: 1) Document it and provide a tool for easily upgrading a venv in this situation. This may be adequate. In practice the situation is quite rare: 2.6.8/2.7.3 is the only actual example in the history of virtualenv that I'm aware of. The disadvantage is that if the problem does occur, the error will probably be quite confusing and seemingly unrelated to pyvenv. I think this is the way to go, for basically the same reasons that we did it this way this time: there's no good reason to pay an ongoing cost to further mitigate the risks associated with an already incredibly rare event. This seems to be the rough consensus. I'll update the PEP with a note about this, and we'll consider switching back to symlink-by-default on Linux. Carl ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
Carl Meyer oddbird.net> writes: > them in sync). IOW, if you want real full isolation from a system > Python, you build your own Python, you don't use pyvenv. For the interpreter you can use your own Python, but you would still use pyvenv, as the venv is still useful for you to have an isolated set of library dependencies for a project. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recording BDFL delegates for PEPs
On May 06, 2012, at 09:31 AM, Antoine Pitrou wrote: >I have to ask - is email obfuscation still useful these days? I think it's more important that Python developers (especially those submitting or pronouncing on PEPs) can be contacted by other Python developers. I *personally* don't care about my pdo address getting obfuscated, and would opt for email address inclusion. I can appreciate that others might feel differently. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice
On May 06, 2012, at 03:08 PM, Nick Coghlan wrote: >I'll see if I can figure out something - I may just put in text like >"if you're at all unsure about what needs to be done, email the PEP >editors anyway". The diff looks good, thanks. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recording BDFL delegates for PEPs
On Sunday, May 6, 2012, Barry Warsaw wrote: > On May 06, 2012, at 09:31 AM, Antoine Pitrou wrote: > > >I have to ask - is email obfuscation still useful these days? > > I think it's more important that Python developers (especially those > submitting or pronouncing on PEPs) can be contacted by other Python > developers. I *personally* don't care about my pdo address getting > obfuscated, and would opt for email address inclusion. I can appreciate > that > others might feel differently. +1 u -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recording BDFL delegates for PEPs
Antoine Pitrou writes: > I have to ask - is email obfuscation still useful these days? It's hard to say. It's still a FAQ on Mailman lists, so people still believe it's useful. I don't think there's hard evidence either way (even guessing depends on the economics of the spamming business, and only the spammers really know that). > I would have thought most people protect from spam by using spam > filters, not by trying to conceal their addresses. Concealing addresses is most definitely a useful way to avoid spam. However, I would guess that the effective way to do it is to have a personal address that is never used anywhere that is easily trawled, not to try to obfuscate addresses that are visible on the web or in posts to open mailing lists or Usenet. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does trunk still support any compilers that *don't* allow declaring variables after code?
On 02.05.2012 15:37, Matt Joiner wrote: On May 2, 2012 6:00 PM, "Antoine Pitrou" mailto:[email protected]>> wrote: > > On Wed, 02 May 2012 01:43:32 -0700 > Larry Hastings mailto:[email protected]>> wrote: > > > > I realize we can't jump to C99 because of A Certain Compiler. (Its name > > rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even that > > compiler added this extension in the early 90s. > > > > Do we officially support any C compilers that *don't* permit > > "intermingled variable declarations and code"? Do we *unofficially* > > support any? And if we do, what do we gain? > > Well, there's this one called MSVC, which we support quite officially. Not sure if comic genius or can't rhyme. This rhyming non-sense is surely above the English abilities of many of us foreigners. I had to read Larry's text five times (two times after you indicated that it indeed ought to rhyme - it finally worked when I read it aloud). So, folks: if you want to be understood, please keep the obfuscation of the English language to a fairly low level. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does trunk still support any compilers that *don't* allow declaring variables after code?
I realize we can't jump to C99 because of A Certain Compiler. (Its name rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even that compiler added this extension in the early 90s. No, it didn't. The MSVC version that we currently use (VS 2008) still doesn't support it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
