[Python-Dev] Failed issue tracker submission
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:
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 2EFFC1DE47
for ; 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 ; 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 ; 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 )
id 1RNKys-0002nh-Es
for [email protected]; Mon, 07 Nov 2011 09:55:02 +0100
Date: Mon, 07 Nov 2011 09:55:02 +0100
Message-Id:
Content-Type: text/plain; charset="utf8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
From: [email protected]
To: [email protected]
Subject: [issue13661] [status=clos
Re: [Python-Dev] Packaging and binary distributions
Martin v. Löwis v.loewis.de> writes:
>
> Again, that's a bdist_msi implementation issue. It could generate custom
> actions that run the "proper" setup.cfg hooks (I presume - I have no
> idea what a setup.cfg hook actually is).
>
I know that custom hooks are quite powerful, but my comment was about having
the functionality in Python. Here's an example of a working hooks.py:
import os
import sys
if os.name == 'nt':
def get_personal_path():
from ctypes import (wintypes, windll, create_unicode_buffer, WinError,
c_int, HRESULT)
from ctypes.wintypes import HWND, HANDLE, DWORD, LPWSTR, MAX_PATH
CSIDL_PERSONAL = 5
# We use an older API to remain XP-compatible.
SHGetFolderPath = windll.shell32.SHGetFolderPathW
SHGetFolderPath.argtypes = [HWND, c_int, HANDLE, DWORD, LPWSTR]
SHGetFolderPath.restype = DWORD
path = create_unicode_buffer(MAX_PATH)
hr = SHGetFolderPath(0, CSIDL_PERSONAL, 0, 0, path)
if hr != 0:
raise WinError()
return path.value
path = get_personal_path()
del get_personal_path
# Assume ~\Documents\WindowsPowerShell\Modules is in $PSModulePath,
# which should be true in a default installation of PowerShell 2.0.
psroot = os.path.join(path, 'WindowsPowerShell')
psmodules = os.path.join(psroot, 'Modules')
psscripts = os.path.join(psroot, 'Scripts')
def setup(config):
files = config['files']
if os.name != 'nt':
files_to_add = 'virtualenvwrapper.sh = {scripts}'
else:
files_to_add = ('winfiles/ *.ps* = '
'{psmodules}/virtualenvwrapper\n'
'winfiles/ vew_profile.ps1 = {psscripts}')
if 'resources' not in files:
files['resources'] = files_to_add
else:
files['resources'] += '\n%s' % files_to_add
def pre_install_data(cmd):
if os.name == 'nt':
cmd.categories['psmodules'] = psmodules
cmd.categories['psscripts'] = psscripts
cmd.categories['psroot'] = psroot
which works with the following setup.cfg:
[global]
setup_hooks = hooks.setup
[install_data]
pre-hook.win32 = hooks.pre_install_data
categories =
cat1 = /path/one
# comment
cat2 = /path/two
#[install_dist]
#post-hook.win32 = hooks.post_install_dist
[metadata]
name = nemo
version = 0.1
summary = New Environments Made, Obviously
description = A tool to manage virtual environments
download_url = UNKNOWN
home_page = https://bitbucket.org/vinay.sajip/nemo
author = Vinay Sajip
author_email = [email protected]
license = BSD
classifier = Development Status :: 3 - Alpha
Programming Language :: Python :: 3
Operating System :: OS Independent
Intended Audience :: System Administrators
Intended Audience :: Developers
License :: OSI Approved :: BSD License
requires_python = >= 3.3
[files]
packages = nemo
virtualenvwrapper
scripts =
nemo = nemo.main
extra_files =
hooks.py
winfiles/*
# Additional esources are added in hooks based on platform
resources =
nemo/scripts/** = {purelib}
I'm curious to know how this level of flexibility can be achieved with the
MSI format: I know one can code the equivalent logic in C (for example) in
a custom action, but don't know how you can keep the logic in Python.
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] Packaging and binary distributions
On 7 November 2011 09:26, Vinay Sajip wrote: > Martin v. Löwis v.loewis.de> writes: > >> >> Again, that's a bdist_msi implementation issue. It could generate custom >> actions that run the "proper" setup.cfg hooks (I presume - I have no >> idea what a setup.cfg hook actually is). >> > > I know that custom hooks are quite powerful, but my comment was about having > the functionality in Python. Here's an example of a working hooks.py: It seems to me that there are two separate things going on in this sample. It's not 100% clear that they are separate, at first glance, as packaging currently doesn't make a strong distinction between things going on at "build" time, and things going on at "install" time. This is essentially because the idea of binary installs is not fundamental to the design. (Thanks for sharing this example, btw, I hadn't really spotted this issue until I saw the code here). Suppose you have two people involved - the "packager" who uses the source code to create a binary distribution (MSI, wininst, zip, doesn't matter - conceptually, it's a set of "final" files that need no further processing and can just be put in the correct locations on the target PC) and the "end user" who takes that binary distribution and installs it on his PC. Some of the hook code is designed to run at "build" time (the stuff that adds the right resource files). This can be run on the packager's machine quite happily, as long as the packager is using the same OS as the end user. However, other parts of the hook code (the stuff that defines the custom categories) must run on the end user's PC, as it detects specific aspects of the target PC configuration. I think Martin is only really interested in the second type of hook here. I know that I am, insofar as they are the only type I would expect to need to support if I were building a new binary distribution format. But without the two types being more clearly separated, it's not obvious that it's possible to "just support one type" in quite that sense... Paul. PS There are subtleties here, of course - byte-compiling .py files is probably an install-time action rather than a build-time one, so my "no further processing required" comment isn't 100% true. But the basic principle certainly applies. ___ 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] Packaging and binary distributions
> > It seems to me that there are two separate things going on in this > sample. It's not 100% clear that they are separate, at first glance, > as packaging currently doesn't make a strong distinction between > things going on at "build" time, and things going on at > "install" > time. This is essentially because the idea of binary installs is not > fundamental to the design. (Thanks for sharing this example, btw, I > hadn't really spotted this issue until I saw the code here). > > Suppose you have two people involved - the "packager" who uses the > source code to create a binary distribution (MSI, wininst, zip, > doesn't matter - conceptually, it's a set of "final" files > that need > no further processing and can just be put in the correct locations on > the target PC) and the "end user" who takes that binary distribution > and installs it on his PC. > > Some of the hook code is designed to run at "build" time (the stuff > that adds the right resource files). This can be run on the packager's > machine quite happily, as long as the packager is using the same OS as > the end user. However, other parts of the hook code (the stuff that > defines the custom categories) must run on the end user's PC, as it > detects specific aspects of the target PC configuration. In this case at least, the code *all* runs at installation time: the distributed package contains all files for all platforms, and at installation time the choice is made as to which files to actually install from the installation directory to the target directories. While this might not be ideal for all packagers, the only downside of having all files for all platforms available in a single distribution is disk space - an increasingly cheap commodity. OTOH there is some advantage in having a single package which would be usable on all platforms (supported by the package being distributed), albeit perhaps for a particular version of Python. > I think Martin is only really interested in the second type of hook > here. I know that I am, insofar as they are the only type I would > expect to need to support if I were building a new binary distribution > format. But without the two types being more clearly separated, it's > not obvious that it's possible to "just support one type" in quite > that sense... In terms of the flexibility required, the code to determine the "personal path" is being run at installation time, to determine the target folder for the PowerShell scripts. It's this kind of flexibility (by which I mean Python coded logic) that I don't see how to easily provide in the MSI format, short of recoding in e.g. C, in a custom action DLL or EXE. (This latter approach is what I've used in the PEP 397 launcher MSI.) 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] [Python-checkins] cpython: quote the type name for improved readability
Hi,
> http://hg.python.org/cpython/rev/bbc929bc2224
> user:Philip Jenvey
> summary:
> quote the type name for improved readability
>
> files:
> Python/bltinmodule.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
> --- a/Python/bltinmodule.c
> +++ b/Python/bltinmodule.c
> @@ -1121,7 +1121,7 @@
> return NULL;
> if (!PyIter_Check(it)) {
> PyErr_Format(PyExc_TypeError,
> -"%.200s object is not an iterator",
> +"'%.200s' object is not an iterator",
> it->ob_type->tp_name);
> return NULL;
> }
What about displaying the repr of the type object?
___
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] cpython: quote the type name for improved readability
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user:Philip Jenvey
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Python/bltinmodule.c b/Python/bltinmodule.c
--- a/Python/bltinmodule.c
+++ b/Python/bltinmodule.c
@@ -1121,7 +1121,7 @@
return NULL;
if (!PyIter_Check(it)) {
PyErr_Format(PyExc_TypeError,
-"%.200s object is not an iterator",
+"'%.200s' object is not an iterator",
it->ob_type->tp_name);
return NULL;
}
What about displaying the repr of the type object?
While I agree that this is more readable, quoted type names are rather rare
if not pretty much unprecedented in core exception messages, so this is
definitely not the only place that would need changing.
However, note that arbitrarily changing exception messages always breaks
someone's doctests, so my personal preference would be to keep it as it was.
Stefan
___
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] ctypes: alignment of (simple) types
Hi all,
gcc allows to set alignments for typedefs like:
typedef double MyDouble __attribute__((__aligned__(8)));
Now if i use this new type within a structure:
struct s {
char c;
MyDouble d;
};
The following holds: sizeof(struct s) == 16 and offsetof(struct s, d) == 8.
ctypes doesn't seem to support this, although i saw a 'padded' function on
the ctypes-users mailinglist which dynamically insert padding fields. I would
consider this more or less a hack :)
What do you think about adding a special attribute '_align_' which, if set for
a data type overrides the hardcoded align property of that type?
--
Michael
___
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] ctypes: alignment of (simple) types
Hi, 2011/11/7 Michael Walle > What do you think about adding a special attribute '_align_' which, if set > for > a data type overrides the hardcoded align property of that type? > It's a good idea. But you should also consider the other feature requests around custom alignments. IMO a good thing would be a way to specify a function that computes sizes and alignments, that one can override to implement specific compiler features. -- Amaury Forgeot d'Arc ___ 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
