From jcea at jcea.es Wed Aug 1 05:58:06 2012
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 01 Aug 2012 05:58:06 +0200
Subject: [Python-Dev] HTTPS repositories failing when using selfsigned certs
Message-ID: <5018A94E.1050104@jcea.es>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My mercurial clone is , and today I
can't create a patch from it (in the bug tracker). No explanation in
the web interface, but checking the sourcecode of the resulting page,
I see a SSL certificate failure.
So, looks like bugs.python.org is now verifying repository certificates.
My certificate is selfsigned and, moreover, it is behind a SNI server,
so the certificate python.org is getting is a selfsigned "jcea.es"
certificate.
What can I do, beside buying a "real" cert?.
Do we have a certificate whitelist, like mercurial?. In my .hgrc, I use
"""
[hostfingerprints]
# En realidad es www.jcea.es. hg.jcea.es esta tras SNI
hg.jcea.es = 54:7e:a7:36:56:c6:80:41:f8:fd:d6:c0:95:44:68:a9:93:58:ca:4c
"""
PS: If I try to use the http version of my repository
(), I get an error: "('invalid token',
97)".
- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBUBipTplgi5GaxT1NAQKyjQP9F1rIKSlDIs8uHLrhIVmaOodRH3umYeyl
zhkiGm34+Cw6I22OQre3VoJ+9vrUF/Go/LpU+UpAH5adzgq4Xfef3Q8jRhclSZmU
ADvGpKhmlzDCahxsQoYXD7UHkc/BLkfNvx+q0wzfDUELbinLyITF4pp2/dLtoNtN
LFG9te1M55A=
=pgh1
-----END PGP SIGNATURE-----
From mark at hotpy.org Wed Aug 1 10:46:35 2012
From: mark at hotpy.org (Mark Shannon)
Date: Wed, 01 Aug 2012 09:46:35 +0100
Subject: [Python-Dev] PEP 0424: A method for exposing a length hint
In-Reply-To:
References:
Message-ID: <5018ECEB.4060403@hotpy.org>
While the idea behind PEP 424 is sound, the text of the PEP is rather vague and missing a lot of details.
There was extended discussion on the details, but none of that has appeared in the PEP yet.
So Alex, how about adding those details?
Also the rationale is rather poor.
Given that CPython is the reference implementation, PyPy should be compared to CPython, not vice-versa.
Reversing PyPy and CPython in the rationale gives:
'''
Being able to pre-allocate lists based on the expected size, as estimated by __length_hint__,
can be a significant optimization.
PyPy has been observed to run some code slower than CPython, purely because this optimization is absent.
'''
Which is a PyPy bug report, not a rationale for a PEP ;)
Perhaps a better rationale would something along the lines of:
'''
Adding a __length_hint__ method to the iterator protocol allows sequences, notably lists,
to be initialised from iterators with only a single resize operation.
This allows sequences to be intialised quickly, yet have a small growth factor, reducing memory use.
'''
Cheers,
Mark.
From fijall at gmail.com Wed Aug 1 11:39:57 2012
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 1 Aug 2012 11:39:57 +0200
Subject: [Python-Dev] PEP 0424: A method for exposing a length hint
In-Reply-To: <5018ECEB.4060403@hotpy.org>
References:
<5018ECEB.4060403@hotpy.org>
Message-ID:
On Wed, Aug 1, 2012 at 10:46 AM, Mark Shannon wrote:
> While the idea behind PEP 424 is sound, the text of the PEP is rather vague
> and missing a lot of details.
> There was extended discussion on the details, but none of that has appeared
> in the PEP yet.
>
> So Alex, how about adding those details?
>
> Also the rationale is rather poor.
> Given that CPython is the reference implementation, PyPy should be compared
> to CPython, not vice-versa.
> Reversing PyPy and CPython in the rationale gives:
>
> '''
> Being able to pre-allocate lists based on the expected size, as estimated by
> __length_hint__,
>
> can be a significant optimization.
> PyPy has been observed to run some code slower than CPython, purely because
> this optimization is absent.
> '''
>
> Which is a PyPy bug report, not a rationale for a PEP ;)
>
> Perhaps a better rationale would something along the lines of:
>
> '''
> Adding a __length_hint__ method to the iterator protocol allows sequences,
> notably lists,
> to be initialised from iterators with only a single resize operation.
> This allows sequences to be intialised quickly, yet have a small growth
> factor, reducing memory use.
> '''
>
Hi Mark.
It's not about saving memory. It really is about speed. Noone bothered
measuring cpython with length hint disabled to compare, however we did
that for pypy hence the rationale contains it. It's merely to state
"this seems like an important optimization". Since the C-level code
involved is rather similar (it's mostly runtime anyway), it seems
reasonable to draw a conclusion that removing length hint from cpython
would cause slowdown.
Cheers,
fijal
From mark at hotpy.org Wed Aug 1 12:06:19 2012
From: mark at hotpy.org (Mark Shannon)
Date: Wed, 01 Aug 2012 11:06:19 +0100
Subject: [Python-Dev] PEP 0424: A method for exposing a length hint
In-Reply-To:
References:
<5018ECEB.4060403@hotpy.org>
Message-ID: <5018FF9B.8030200@hotpy.org>
Maciej Fijalkowski wrote:
> On Wed, Aug 1, 2012 at 10:46 AM, Mark Shannon wrote:
>> While the idea behind PEP 424 is sound, the text of the PEP is rather vague
>> and missing a lot of details.
>> There was extended discussion on the details, but none of that has appeared
>> in the PEP yet.
>>
>> So Alex, how about adding those details?
>>
>> Also the rationale is rather poor.
>> Given that CPython is the reference implementation, PyPy should be compared
>> to CPython, not vice-versa.
>> Reversing PyPy and CPython in the rationale gives:
>>
>> '''
>> Being able to pre-allocate lists based on the expected size, as estimated by
>> __length_hint__,
>>
>> can be a significant optimization.
>> PyPy has been observed to run some code slower than CPython, purely because
>> this optimization is absent.
>> '''
>>
>> Which is a PyPy bug report, not a rationale for a PEP ;)
>>
>> Perhaps a better rationale would something along the lines of:
>>
>> '''
>> Adding a __length_hint__ method to the iterator protocol allows sequences,
>> notably lists,
>> to be initialised from iterators with only a single resize operation.
>> This allows sequences to be intialised quickly, yet have a small growth
>> factor, reducing memory use.
>> '''
>>
>
> Hi Mark.
>
> It's not about saving memory. It really is about speed. Noone bothered
> measuring cpython with length hint disabled to compare, however we did
> that for pypy hence the rationale contains it. It's merely to state
> "this seems like an important optimization". Since the C-level code
> involved is rather similar (it's mostly runtime anyway), it seems
> reasonable to draw a conclusion that removing length hint from cpython
> would cause slowdown.
It is not about making it faster *or* saving memory, but *both*.
Without __length_hint__ there is a trade off between speed and memory use.
You can have speed at the cost of memory by increasing the resize factor.
With __length_hint__ you can get both speed and good memory use.
Cheers,
Mark
From fijall at gmail.com Wed Aug 1 12:37:23 2012
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 1 Aug 2012 12:37:23 +0200
Subject: [Python-Dev] PEP 0424: A method for exposing a length hint
In-Reply-To: <5018FF9B.8030200@hotpy.org>
References:
<5018ECEB.4060403@hotpy.org>
<5018FF9B.8030200@hotpy.org>
Message-ID:
On Wed, Aug 1, 2012 at 12:06 PM, Mark Shannon wrote:
> Maciej Fijalkowski wrote:
>>
>> On Wed, Aug 1, 2012 at 10:46 AM, Mark Shannon wrote:
>>>
>>> While the idea behind PEP 424 is sound, the text of the PEP is rather
>>> vague
>>> and missing a lot of details.
>>> There was extended discussion on the details, but none of that has
>>> appeared
>>> in the PEP yet.
>>>
>>> So Alex, how about adding those details?
>>>
>>> Also the rationale is rather poor.
>>> Given that CPython is the reference implementation, PyPy should be
>>> compared
>>> to CPython, not vice-versa.
>>> Reversing PyPy and CPython in the rationale gives:
>>>
>>> '''
>>> Being able to pre-allocate lists based on the expected size, as estimated
>>> by
>>> __length_hint__,
>>>
>>> can be a significant optimization.
>>> PyPy has been observed to run some code slower than CPython, purely
>>> because
>>> this optimization is absent.
>>> '''
>>>
>>> Which is a PyPy bug report, not a rationale for a PEP ;)
>>>
>>> Perhaps a better rationale would something along the lines of:
>>>
>>> '''
>>> Adding a __length_hint__ method to the iterator protocol allows
>>> sequences,
>>> notably lists,
>>> to be initialised from iterators with only a single resize operation.
>>> This allows sequences to be intialised quickly, yet have a small growth
>>> factor, reducing memory use.
>>> '''
>>>
>>
>> Hi Mark.
>>
>> It's not about saving memory. It really is about speed. Noone bothered
>> measuring cpython with length hint disabled to compare, however we did
>> that for pypy hence the rationale contains it. It's merely to state
>> "this seems like an important optimization". Since the C-level code
>> involved is rather similar (it's mostly runtime anyway), it seems
>> reasonable to draw a conclusion that removing length hint from cpython
>> would cause slowdown.
>
>
> It is not about making it faster *or* saving memory, but *both*.
> Without __length_hint__ there is a trade off between speed and memory use.
> You can have speed at the cost of memory by increasing the resize factor.
No, you cannot.
if you allocate a huge region, you're not gonna make much of speed,
because at the end you need to copy stuff anyway. Besides large
allocations are slow. With length hint that is correct (sometimes you
can do that) you have a zero-copy scenario
From solipsis at pitrou.net Wed Aug 1 14:12:54 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 1 Aug 2012 14:12:54 +0200
Subject: [Python-Dev] HTTPS repositories failing when using selfsigned
certs
References: <5018A94E.1050104@jcea.es>
Message-ID: <20120801141254.1af9a1fe@pitrou.net>
On Wed, 01 Aug 2012 05:58:06 +0200
Jesus Cea wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> My mercurial clone is , and today I
> can't create a patch from it (in the bug tracker). No explanation in
> the web interface, but checking the sourcecode of the resulting page,
> I see a SSL certificate failure.
>
> So, looks like bugs.python.org is now verifying repository certificates.
>
> My certificate is selfsigned and, moreover, it is behind a SNI server,
> so the certificate python.org is getting is a selfsigned "jcea.es"
> certificate.
>
> What can I do, beside buying a "real" cert?.
Why don't you just use a HTTP URL?
Regards
Antoine.
--
Software development and contracting: http://pro.pitrou.net
From solipsis at pitrou.net Wed Aug 1 14:19:19 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 1 Aug 2012 14:19:19 +0200
Subject: [Python-Dev] HTTPS repositories failing when using selfsigned
certs
References: <5018A94E.1050104@jcea.es>
<20120801141254.1af9a1fe@pitrou.net>
Message-ID: <20120801141919.5df8b1ce@pitrou.net>
On Wed, 1 Aug 2012 14:12:54 +0200
Antoine Pitrou wrote:
> On Wed, 01 Aug 2012 05:58:06 +0200
> Jesus Cea wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > My mercurial clone is , and today I
> > can't create a patch from it (in the bug tracker). No explanation in
> > the web interface, but checking the sourcecode of the resulting page,
> > I see a SSL certificate failure.
> >
> > So, looks like bugs.python.org is now verifying repository certificates.
> >
> > My certificate is selfsigned and, moreover, it is behind a SNI server,
> > so the certificate python.org is getting is a selfsigned "jcea.es"
> > certificate.
> >
> > What can I do, beside buying a "real" cert?.
>
> Why don't you just use a HTTP URL?
Whoops, I hadn't seen the P.S. in your e-mail:
> PS: If I try to use the http version of my repository
> (), I get an error: "('invalid token',
> 97)".
In this case the issue with the http version should perhaps be figured
out first.
Regards
Antoine.
--
Software development and contracting: http://pro.pitrou.net
From storchaka at gmail.com Wed Aug 1 22:52:02 2012
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 01 Aug 2012 23:52:02 +0300
Subject: [Python-Dev] cpython: Fix findnocoding.p and pysource.py scripts
In-Reply-To: <3WnN5F1BX5zPgm@mail.python.org>
References: <3WnN5F1BX5zPgm@mail.python.org>
Message-ID: <501996F2.7000208@gmail.com>
On 01.08.12 21:16, victor.stinner wrote:
> http://hg.python.org/cpython/rev/67d36e8ddcfc
> changeset: 78375:67d36e8ddcfc
> user: Victor Stinner
> date: Wed Aug 01 20:12:51 2012 +0200
> summary:
> Fix findnocoding.p and pysource.py scripts
>
> I suppose that these scripts didn't work since Python 3.0.
> - line1 = infile.readline()
> - line2 = infile.readline()
> + with infile:
> + line1 = infile.readline()
> + line2 = infile.readline()
>
> - if get_declaration(line1) or get_declaration(line2):
> - # the file does have an encoding declaration, so trust it
> - infile.close()
> - return False
> + if get_declaration(line1) or get_declaration(line2):
> + # the file does have an encoding declaration, so trust it
> + infile.close()
> + return False
infile.close() is unnecessary here.
From victor.stinner at gmail.com Thu Aug 2 00:12:17 2012
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 2 Aug 2012 00:12:17 +0200
Subject: [Python-Dev] cpython: Fix findnocoding.p and pysource.py scripts
In-Reply-To: <501996F2.7000208@gmail.com>
References: <3WnN5F1BX5zPgm@mail.python.org>
<501996F2.7000208@gmail.com>
Message-ID:
2012/8/1 Serhiy Storchaka :
>> changeset: 78375:67d36e8ddcfc
>> Fix findnocoding.p and pysource.py scripts
>>
>
>> - line1 = infile.readline()
>> - line2 = infile.readline()
>> + with infile:
>> + line1 = infile.readline()
>> + line2 = infile.readline()
>>
>> - if get_declaration(line1) or get_declaration(line2):
>> - # the file does have an encoding declaration, so trust it
>> - infile.close()
>> - return False
>> + if get_declaration(line1) or get_declaration(line2):
>> + # the file does have an encoding declaration, so trust it
>> + infile.close()
>> + return False
>
> infile.close() is unnecessary here.
Ah yes correct, I forgot this one. The new changeset 8ace059cdffd removes it.
It is not perfect, there is still a race condition in
looks_like_python() (pysource.py) if KeyboardInterrupt occurs between
the file is opened and the beginning of the "with infile" block, but
it don't think that it is really important ;-)
Victor
From shanthulinux at gmail.com Thu Aug 2 09:28:36 2012
From: shanthulinux at gmail.com (Shanth Kumar)
Date: Thu, 2 Aug 2012 12:58:36 +0530
Subject: [Python-Dev] Introduction
Message-ID:
Hi I am Shanthkumar from Bangalore, India, working for a software firm.
Good to see the mailing group, as i am new to python curious to ask you
people couple of queireis.
--
Regards...,
Shanthkumara O.D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From catch-all at masklinn.net Thu Aug 2 09:44:26 2012
From: catch-all at masklinn.net (Xavier Morel)
Date: Thu, 2 Aug 2012 09:44:26 +0200
Subject: [Python-Dev] Introduction
In-Reply-To:
References:
Message-ID: <560C7568-ED90-4AA2-BABA-4C8E96FFC844@masklinn.net>
On 2012-08-02, at 09:28 , Shanth Kumar wrote:
> Hi I am Shanthkumar from Bangalore, India, working for a software firm.
> Good to see the mailing group, as i am new to python curious to ask you
> people couple of queireis.
I fear that is very likely the wrong mailing list for that: python-dev
is about the development of the CPython runtime and the language
itself, not so much about learning it and developing in it.
You probably want python-list
(http://mail.python.org/mailman/listinfo/python-list) or tutor
(http://mail.python.org/mailman/listinfo/tutor), or your local user
group's mailing list (http://mail.python.org/mailman/listinfo/bangpypers)
From roundup-admin at psf.upfronthosting.co.za Thu Aug 2 13:45:36 2012
From: roundup-admin at psf.upfronthosting.co.za (Python tracker)
Date: Thu, 02 Aug 2012 11:45:36 +0000
Subject: [Python-Dev] Failed issue tracker submission
Message-ID: <20120802114536.4316D1CDFE@psf.upfronthosting.co.za>
There was a problem with the message you sent:
This issue can't be closed until issue 15502 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.
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.
-------------- next part --------------
Return-Path:
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [IPv6:2001:888:2000:d::a6])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 86BB41CD7E
for ; Thu, 2 Aug 2012 13:45:35 +0200 (CEST)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 3WnqMM2J6szNbw
for ; Thu, 2 Aug 2012 13:45:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1343907935; bh=gCR6sftsrpIrVDajA2ztlOvXtnpd1hd96n2LwhPSZkk=;
h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To:
Subject:Message-Id:Date;
b=eGlIBm9r/zVe4tZZOqtKy8ctuyEEfVHryOb98//t3VAYMgz7Th9wKgpUWNd6OEJnQ
hWSOrYKAgNROXrwx+ITyPbwGgMbE1CwRfQiCuxe6RMTQJqoM8kS1MebdE/JiBVrD6U
0h/vjTxlMpKY1YjzbOCqvmuHnaSuTRo3LLieIRRc=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 02 Aug 2012 13:45:35 +0200
Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72])
by mail.python.org (Postfix) with ESMTP
for ; Thu, 2 Aug 2012 13:45:34 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: python-dev at python.org
To: report at bugs.python.org
Subject: [issue15519] [status=closed; resolution=fixed;
stage=committed/rejected]
Message-Id: <3WnqMM2J6szNbw at mail.python.org>
Date: Thu, 2 Aug 2012 13:45:35 +0200 (CEST)
TmV3IGNoYW5nZXNldCBhMWFjMWUxM2M1YTAgYnkgTmljayBDb2dobGFuIGluIGJyYW5jaCAnZGVm
YXVsdCc6CkNsb3NlICMxNTUxOTogUHJvcGVybHkgZXhwb3NlIFdpbmRvd3NSZWdpc3RyeUZpbmRl
ciBpbiBpbXBvcnRsaWIgYW5kIGJyaW5nIHRoZSBuYW1lIGludG8gbGluZSB3aXRoIG5vcm1hbCBp
bXBvcnQgdGVybWlub2xvZ3kuIE9yaWdpbmFsIHBhdGNoIGJ5IEVyaWMgU25vdwpodHRwOi8vaGcu
cHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9hMWFjMWUxM2M1YTAK
From barry at python.org Thu Aug 2 16:32:19 2012
From: barry at python.org (Barry Warsaw)
Date: Thu, 2 Aug 2012 10:32:19 -0400
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the
importlib.PathFinder docs and docstring more in line
In-Reply-To: <3Wns631KFWzPhs@mail.python.org>
References: <3Wns631KFWzPhs@mail.python.org>
Message-ID: <20120802103219.19acba49@resist.wooz.org>
On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote:
>http://hg.python.org/cpython/rev/1f8351cf00f3
>changeset: 78382:1f8351cf00f3
>user: Nick Coghlan
>date: Thu Aug 02 23:03:58 2012 +1000
>summary:
> Issue #15502: Bring the importlib.PathFinder docs and docstring more in line with the new import system documentation, and fix various parts of the new docs that weren't quite right given PEP 420 or were otherwise a bit misleading. Also note the key terminology problem still being discussed in the issue
>
>files:
> Doc/library/importlib.rst | 15 +-
> Doc/reference/import.rst | 221 +-
> Lib/importlib/_bootstrap.py | 8 +-
> Python/importlib.h | 2583 +++++++++++-----------
> 4 files changed, 1449 insertions(+), 1378 deletions(-)
>
>
>diff --git a/Doc/reference/import.rst b/Doc/reference/import.rst
>--- a/Doc/reference/import.rst
>+++ b/Doc/reference/import.rst
>@@ -69,7 +75,7 @@
>
> It's important to keep in mind that all packages are modules, but not all
> modules are packages. Or put another way, packages are just a special kind of
>-module. Specifically, any module that contains an ``__path__`` attribute is
>+module. Specifically, any module that contains a ``__path__`` attribute is
I find this change hilarious! Is it "an under-under path" or "a dunder path"?
Personally, I think word "dunder" should never be used unless it's followed by
the word "mifflin", but that might be a bit too regional. Or maybe too old
skool (yeah, I know all the kids love the dunder).
I suppose I don't care that much, but it would be useful to have some
consistency, like whether we use American or British spellings.
>@@ -90,7 +96,7 @@
> packages are traditional packages as they existed in Python 3.2 and earlier.
> A regular package is typically implemented as a directory containing an
> ``__init__.py`` file. When a regular package is imported, this
>-``__init__.py`` file is implicitly imported, and the objects it defines are
>+``__init__.py`` file is implicitly executed, and the objects it defines are
Perhaps "loaded" instead of either "imported" or "executed"?
>@@ -107,9 +113,9 @@
> three/
> __init__.py
>
>-Importing ``parent.one`` will implicitly import ``parent/__init__.py`` and
>+Importing ``parent.one`` will implicitly execute ``parent/__init__.py`` and
Same.
> ``parent/one/__init__.py``. Subsequent imports of ``parent.two`` or
>-``parent.three`` will import ``parent/two/__init__.py`` and
>+``parent.three`` will execute ``parent/two/__init__.py`` and
And here.
> ``parent/three/__init__.py`` respectively.
>
>
>@@ -128,6 +134,12 @@
> objects on the file system; they may be virtual modules that have no concrete
> representation.
>
>+Namespace packages do not use an ordinary list for their ``__path__``
>+attribute. They instead use a custom iterable type which will automatically
>+perform a new search for package portions on the next import attempt within
>+that package if the path of their parent package (or :data:`sys.path` for a
>+top level package) changes.
Nice addition. I can't help but suggest a slight rephrasing:
Namespace packages use a custom iterable type for their ``__path__``
attribute, so that changes in their parent package's path (or :data:`sys.path`
for a top level package) are handled automatically.
>@@ -172,14 +184,18 @@
> :exc:`ImportError` is raised. If the module name is missing, Python will
> continue searching for the module.
>
>-:data:`sys.modules` is writable. Deleting a key will not destroy the
>-associated module, but it will invalidate the cache entry for the named
>-module, causing Python to search anew for the named module upon its next
>-import. Beware though, because if you keep a reference to the module object,
>+:data:`sys.modules` is writable. Deleting a key may not destroy the
>+associated module (as other modules may hold references to it),
s/as other modules may hold references to it/due to circular references/
>@@ -369,7 +404,7 @@
>
> Here are the exact rules used:
>
>- * If the module has an ``__loader__`` and that loader has a
>+ * If the module has a ``__loader__`` and that loader has a
> :meth:`module_repr()` method, call it with a single argument, which is the
> module object. The value returned is used as the module's repr.
>
>@@ -377,10 +412,10 @@
> and discarded, and the calculation of the module's repr continues as if
> :meth:`module_repr()` did not exist.
>
>- * If the module has an ``__file__`` attribute, this is used as part of the
>+ * If the module has a ``__file__`` attribute, this is used as part of the
> module's repr.
>
>- * If the module has no ``__file__`` but does have an ``__loader__``, then the
>+ * If the module has no ``__file__`` but does have a ``__loader__``, then the
> loader's repr is used as part of the module's repr.
>
> * Otherwise, just use the module's ``__name__`` in the repr.
C'mon Michael Scott, make it stop! Do you remember the episode where Dwight
and Jim team up to... Oh, I was in stitches!
>@@ -430,15 +467,20 @@
> path`, which contains a list of :term:`path entries `. Each path
> entry names a location to search for modules.
>
>-Path entries may name file system locations, and by default the :term:`path
>-importer` knows how to provide traditional file system imports. It implements
>-all the semantics for finding modules on the file system, handling special
>-file types such as Python source code (``.py`` files), Python byte code
>-(``.pyc`` and ``.pyo`` files) and shared libraries (e.g. ``.so`` files).
>+The path importer itself doesn't know how to import anything. Instead, it
>+traverses the individual path entries, associating each of them with a
>+path entry finder that knows how to handle that particular kind of path.
>+
>+The default set of path entry finders implement all the semantics for finding
>+modules on the file system, handling special file types such as Python source
>+code (``.py`` files), Python byte code (``.pyc`` and ``.pyo`` files) and
>+shared libraries (e.g. ``.so`` files). When supported by the :mod:`zipimport`
>+module in the standard library, the default path entry finders also handle
>+loading all of these file types (other than shared libraries) from zipfiles.
s/zipfiles/zip files/
>
> Path entries need not be limited to file system locations. They can refer to
>-the contents of zip files, URLs, database queries, or any other location that
>-can be specified as a string.
>+the URLs, database queries, or any other location that can be specified as a
>+string.
s/the URLs/URLs/
>
> The :term:`path importer` provides additional hooks and protocols so that you
> can extend and customize the types of searchable path entries. For example,
>@@ -534,29 +578,59 @@
> Path entry finder protocol
> --------------------------
>
>-Path entry finders support the same :meth:`find_module()` method that meta
>-path finders support, however path entry finder's :meth:`find_module()`
>-methods are never called with a ``path`` argument.
>-
>-The :meth:`find_module()` method on path entry finders is deprecated though,
>-and instead path entry finders should implement the :meth:`find_loader()`
>-method. If it exists on the path entry finder, :meth:`find_loader()` will
>-always be called instead of :meth:`find_module()`.
>+In order to support imports of modules and initialized packages and also to
>+contribute portions to namespace packages, path entry finders must implement
>+the :meth:`find_loader()` method.
This is an improvement, because it de-emphasizes the deprecated API. Perhaps
add a footnote that describes the legacy API?
> :meth:`find_loader()` takes one argument, the fully qualified name of the
> module being imported. :meth:`find_loader()` returns a 2-tuple where the
> first item is the loader and the second item is a namespace :term:`portion`.
> When the first item (i.e. the loader) is ``None``, this means that while the
>-path entry finder does not have a loader for the named module, it knows that
>-the :term:`path entry` contributes to a namespace portion for the named
>-module. This will almost always be the case where Python is asked to import a
>-:term:`namespace package` that has no physical presence on the file system.
>-When a path entry finder returns ``None`` for the loader, the second item of
>-the 2-tuple return value must be a sequence, although it can be empty.
>+path entry finder does not have a loader for the named module, it knows that the
>+path entry contributes to a namespace portion for the named module. This will
>+almost always be the case where Python is asked to import a namespace package
>+that has no physical presence on the file system. When a path entry finder
>+returns ``None`` for the loader, the second item of the 2-tuple return value
>+must be a sequence, although it can be empty.
>
> If :meth:`find_loader()` returns a non-``None`` loader value, the portion is
>-ignored and the loader is returned from the :term:`path importer`, terminating
>-the :term:`import path` search.
>+ignored and the loader is returned from the path importer, terminating the
>+search through the path entries.
>+
>+For backwards compatibility with other implementations of the import
>+protocol, many path entry finders also support the same,
>+traditional :meth:`find_module()` method that meta path finders support.
>+However path entry finder :meth:`find_module()` methods are never called
>+with a ``path`` argument (they are expected to record the appropriate
>+path information from the initial call to the path hook).
>+
>+The :meth:`find_module()` method on path entry finders is deprecated,
>+as it does not allow the path entry finder to contribute portions to
>+namespace packages. Instead path entry finders should implement the
>+:meth:`find_loader()` method as described above. If it exists on the path
>+entry finder, the import system will always call :meth:`find_loader()`
>+in preference to :meth:`find_module()`.
The above is what could be moved to the footnote.
Cheers,
-Barry
From chris.jerdonek at gmail.com Thu Aug 2 16:41:05 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Thu, 2 Aug 2012 07:41:05 -0700
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the
importlib.PathFinder docs and docstring more in line
In-Reply-To: <20120802103219.19acba49@resist.wooz.org>
References: <3Wns631KFWzPhs@mail.python.org>
<20120802103219.19acba49@resist.wooz.org>
Message-ID:
On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote:
> On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote:
>
>>-module. Specifically, any module that contains an ``__path__`` attribute is
>>+module. Specifically, any module that contains a ``__path__`` attribute is
>
> I find this change hilarious! Is it "an under-under path" or "a dunder path"?
Personally, I just say "path" (same with __init__, __main__, etc) and
rely on context.
--Chris
From solipsis at pitrou.net Thu Aug 2 16:43:12 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 2 Aug 2012 16:43:12 +0200
Subject: [Python-Dev] cpython: Issue #15502: Bring the
importlib.PathFinder docs and docstring more in line
References: <3Wns631KFWzPhs@mail.python.org>
<20120802103219.19acba49@resist.wooz.org>
Message-ID: <20120802164312.6e337335@pitrou.net>
On Thu, 2 Aug 2012 07:41:05 -0700
Chris Jerdonek wrote:
> On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote:
> > On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote:
> >
> >>-module. Specifically, any module that contains an ``__path__`` attribute is
> >>+module. Specifically, any module that contains a ``__path__`` attribute is
> >
> > I find this change hilarious! Is it "an under-under path" or "a dunder path"?
>
> Personally, I just say "path" (same with __init__, __main__, etc) and
> rely on context.
+1.
Regards
Antoine.
--
Software development and contracting: http://pro.pitrou.net
From brett at python.org Thu Aug 2 17:35:55 2012
From: brett at python.org (Brett Cannon)
Date: Thu, 2 Aug 2012 11:35:55 -0400
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the
importlib ABCs into line with the current state of the
In-Reply-To: <3Wnpx25v1RzPhl@mail.python.org>
References: <3Wnpx25v1RzPhl@mail.python.org>
Message-ID:
Mostly as a note to myself (although if someone else wants to change this,
then great), PathEntryFinder.find_loader() specifies self while the other
docs don't bother to list it.
And I just realized that the other classes defined in the importlib docs
don't list their superclasses like MetaPathFinder and PathEntryFinder now
do.
On Thu, Aug 2, 2012 at 7:26 AM, nick.coghlan wrote:
> http://hg.python.org/cpython/rev/184700df5b6a
> changeset: 78379:184700df5b6a
> parent: 78376:8ace059cdffd
> user: Nick Coghlan
> date: Thu Aug 02 21:26:03 2012 +1000
> summary:
> Issue #15502: Bring the importlib ABCs into line with the current state
> of the import protocols given PEP 420. Original patch by Eric Snow.
>
> files:
> Doc/library/importlib.rst | 77 +++++---
> Lib/importlib/abc.py | 82 ++++++---
> Lib/test/test_importlib/source/test_abc_loader.py | 23 +-
> Lib/test/test_importlib/test_abc.py | 7 +-
> Misc/NEWS | 3 +
> 5 files changed, 127 insertions(+), 65 deletions(-)
>
>
> diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst
> --- a/Doc/library/importlib.rst
> +++ b/Doc/library/importlib.rst
> @@ -125,32 +125,49 @@
>
> .. class:: Finder
>
> - An abstract base class representing a :term:`finder`.
> - See :pep:`302` for the exact definition for a finder.
> -
> - .. method:: find_loader(self, fullname):
> -
> - An abstract method for finding a :term:`loader` for the specified
> - module. Returns a 2-tuple of ``(loader, portion)`` where portion
> is a
> - sequence of file system locations contributing to part of a
> namespace
> - package. The sequence may be empty. When present,
> `find_loader()` is
> - preferred over `find_module()`.
> -
> - .. versionadded: 3.3
> -
> - .. method:: find_module(fullname, path=None)
> -
> - An abstract method for finding a :term:`loader` for the specified
> - module. If the :term:`finder` is found on :data:`sys.meta_path`
> and the
> - module to be searched for is a subpackage or module then *path*
> will
> - be the value of :attr:`__path__` from the parent package. If a
> loader
> - cannot be found, ``None`` is returned.
> + An abstract base class representing a :term:`finder`. Finder
> + implementations should derive from (or register with) the more specific
> + :class:`MetaPathFinder` or :class:`PathEntryFinder` ABCs.
>
> .. method:: invalidate_caches()
>
> - An optional method which, when called, should invalidate any
> internal
> - cache used by the finder. Used by :func:`invalidate_caches()` when
> - invalidating the caches of all cached finders.
> + An optional method which, when called, should invalidate any
> internal
> + cache used by the finder. Used by :func:`invalidate_caches()` when
> + invalidating the caches of all cached finders.
> +
> + .. versionchanged:: 3.3
> + The API signatures for meta path finders and path entry finders
> + were separated by PEP 420. Accordingly, the Finder ABC no
> + longer requires implementation of a ``find_module()`` method.
> +
> +
> +.. class:: MetaPathFinder(Finder)
> +
> + An abstract base class representing a :term:`meta path finder`.
> +
> + .. versionadded:: 3.3
> +
> + .. method:: find_module(fullname, path)
> +
> + An abstract method for finding a :term:`loader` for the specified
> + module. If this is a top-level import, *path* will be ``None``.
> + Otheriwse, this is a search for a subpackage or module and *path*
> + will be the value of :attr:`__path__` from the parent
> + package. If a loader cannot be found, ``None`` is returned.
> +
> +
> +.. class:: PathEntryFinder(Finder)
> +
> + An abstract base class representing a :term:`path entry finder`.
> +
> + .. versionadded:: 3.3
> +
> + .. method:: find_loader(self, fullname):
> +
> + An abstract method for finding a :term:`loader` for the specified
> + module. Returns a 2-tuple of ``(loader, portion)`` where portion
> is a
> + sequence of file system locations contributing to part of a
> namespace
> + package. The sequence may be empty.
>
>
> .. class:: Loader
> @@ -569,8 +586,8 @@
>
> An :term:`importer` for built-in modules. All known built-in modules
> are
> listed in :data:`sys.builtin_module_names`. This class implements the
> - :class:`importlib.abc.Finder` and :class:`importlib.abc.InspectLoader`
> - ABCs.
> + :class:`importlib.abc.MetaPathFinder` and
> + :class:`importlib.abc.InspectLoader` ABCs.
>
> Only class methods are defined by this class to alleviate the need for
> instantiation.
> @@ -579,8 +596,8 @@
> .. class:: FrozenImporter
>
> An :term:`importer` for frozen modules. This class implements the
> - :class:`importlib.abc.Finder` and :class:`importlib.abc.InspectLoader`
> - ABCs.
> + :class:`importlib.abc.MetaPathFinder` and
> + :class:`importlib.abc.InspectLoader` ABCs.
>
> Only class methods are defined by this class to alleviate the need for
> instantiation.
> @@ -589,7 +606,7 @@
> .. class:: PathFinder
>
> :term:`Finder` for :data:`sys.path`. This class implements the
> - :class:`importlib.abc.Finder` ABC.
> + :class:`importlib.abc.MetaPathFinder` ABC.
>
> This class does not perfectly mirror the semantics of
> :keyword:`import` in
> terms of :data:`sys.path`. No implicit path hooks are assumed for
> @@ -616,8 +633,8 @@
>
> .. class:: FileFinder(path, \*loader_details)
>
> - A concrete implementation of :class:`importlib.abc.Finder` which caches
> - results from the file system.
> + A concrete implementation of :class:`importlib.abc.PathEntryFinder`
> which
> + caches results from the file system.
>
> The *path* argument is the directory for which the finder is in charge
> of
> searching.
> diff --git a/Lib/importlib/abc.py b/Lib/importlib/abc.py
> --- a/Lib/importlib/abc.py
> +++ b/Lib/importlib/abc.py
> @@ -23,6 +23,61 @@
> abstract_cls.register(frozen_cls)
>
>
> +class Finder(metaclass=abc.ABCMeta):
> +
> + """Common abstract base class for import finders.
> +
> + Finder implementations should derive from the more specific
> + MetaPathFinder or PathEntryFinder ABCs rather than directly from
> Finder.
> + """
> +
> + def find_module(self, fullname, path=None):
> + """An optional legacy method that should find a module.
> + The fullname is a str and the optional path is a str or None.
> + Returns a Loader object.
> +
> + The path finder will use this method only if find_loader() does
> + not exist. It may optionally be implemented for compatibility
> + with legacy third party reimplementations of the import system.
> + """
> + raise NotImplementedError
> +
> + # invalidate_caches() is a completely optional method, so no default
> + # implementation is provided. See the docs for details.
> +
> +
> +class MetaPathFinder(Finder):
> +
> + """Abstract base class for import finders on sys.meta_path."""
> +
> + @abc.abstractmethod
> + def find_module(self, fullname, path):
> + """Abstract method which when implemented should find a module.
> + The fullname is a str and the path is a str or None.
> + Returns a Loader object.
> + """
> + raise NotImplementedError
> +
> +_register(MetaPathFinder, machinery.BuiltinImporter,
> machinery.FrozenImporter,
> + machinery.PathFinder)
> +
> +
> +class PathEntryFinder(Finder):
> +
> + """Abstract base class for path entry finders used by PathFinder."""
> +
> + @abc.abstractmethod
> + def find_loader(self, fullname):
> + """Abstract method which when implemented returns a module loader.
> + The fullname is a str. Returns a 2-tuple of (Loader, portion)
> where
> + portion is a sequence of file system locations contributing to
> part of
> + a namespace package. The sequence may be empty.
> + """
> + raise NotImplementedError
> +
> +_register(PathEntryFinder, machinery.FileFinder)
> +
> +
> class Loader(metaclass=abc.ABCMeta):
>
> """Abstract base class for import loaders."""
> @@ -40,33 +95,6 @@
> raise NotImplementedError
>
>
> -class Finder(metaclass=abc.ABCMeta):
> -
> - """Abstract base class for import finders."""
> -
> - @abc.abstractmethod
> - def find_loader(self, fullname):
> - """Abstract method which when implemented returns a module loader.
> - The fullname is a str. Returns a 2-tuple of (Loader, portion)
> where
> - portion is a sequence of file system locations contributing to
> part of
> - a namespace package. The sequence may be empty. When present,
> - `find_loader()` is preferred over `find_module()`.
> - """
> - raise NotImplementedError
> -
> - @abc.abstractmethod
> - def find_module(self, fullname, path=None):
> - """Abstract method which when implemented should find a module.
> - The fullname is a str and the optional path is a str or None.
> - Returns a Loader object. This method is only called if
> - `find_loader()` is not present.
> - """
> - raise NotImplementedError
> -
> -_register(Finder, machinery.BuiltinImporter, machinery.FrozenImporter,
> - machinery.PathFinder, machinery.FileFinder)
> -
> -
> class ResourceLoader(Loader):
>
> """Abstract base class for loaders which can return data from their
> diff --git a/Lib/test/test_importlib/source/test_abc_loader.py
> b/Lib/test/test_importlib/source/test_abc_loader.py
> --- a/Lib/test/test_importlib/source/test_abc_loader.py
> +++ b/Lib/test/test_importlib/source/test_abc_loader.py
> @@ -778,23 +778,32 @@
> expect = io.IncrementalNewlineDecoder(None, True).decode(source)
> self.assertEqual(mock.get_source(name), expect)
>
> +
> class AbstractMethodImplTests(unittest.TestCase):
>
> """Test the concrete abstractmethod implementations."""
>
> + class MetaPathFinder(abc.MetaPathFinder):
> + def find_module(self, fullname, path):
> + super().find_module(fullname, path)
> +
> + class PathEntryFinder(abc.PathEntryFinder):
> + def find_module(self, _):
> + super().find_module(_)
> +
> + def find_loader(self, _):
> + super().find_loader(_)
> +
> + class Finder(abc.Finder):
> + def find_module(self, fullname, path):
> + super().find_module(fullname, path)
> +
> class Loader(abc.Loader):
> def load_module(self, fullname):
> super().load_module(fullname)
> def module_repr(self, module):
> super().module_repr(module)
>
> - class Finder(abc.Finder):
> - def find_module(self, _):
> - super().find_module(_)
> -
> - def find_loader(self, _):
> - super().find_loader(_)
> -
> class ResourceLoader(Loader, abc.ResourceLoader):
> def get_data(self, _):
> super().get_data(_)
> diff --git a/Lib/test/test_importlib/test_abc.py
> b/Lib/test/test_importlib/test_abc.py
> --- a/Lib/test/test_importlib/test_abc.py
> +++ b/Lib/test/test_importlib/test_abc.py
> @@ -30,11 +30,16 @@
> "{0} is not a superclass of {1}".format(superclass,
> self.__test))
>
>
> -class Finder(InheritanceTests, unittest.TestCase):
> +class MetaPathFinder(InheritanceTests, unittest.TestCase):
>
> + superclasses = [abc.Finder]
> subclasses = [machinery.BuiltinImporter, machinery.FrozenImporter,
> machinery.PathFinder]
>
> +class PathEntryFinder(InheritanceTests, unittest.TestCase):
> +
> + superclasses = [abc.Finder]
> + subclasses = [machinery.FileFinder]
>
> class Loader(InheritanceTests, unittest.TestCase):
>
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -72,6 +72,9 @@
> Library
> -------
>
> +- Issue #15502: Bring the importlib ABCs into line with the current state
> + of the import protocols given PEP 420. Original patch by Eric Snow.
> +
> - Issue #15499: Launching a webbrowser in Unix used to sleep for a few
> seconds. Original patch by Anton Barkovsky.
>
>
> --
> Repository URL: http://hg.python.org/cpython
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From raymond.hettinger at gmail.com Thu Aug 2 17:43:38 2012
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Thu, 2 Aug 2012 08:43:38 -0700
Subject: [Python-Dev] PEP 0424: A method for exposing a length hint
In-Reply-To: <5018ECEB.4060403@hotpy.org>
References:
<5018ECEB.4060403@hotpy.org>
Message-ID: <7F1504FC-DD46-4C8A-B5F4-DA200C179353@gmail.com>
On Aug 1, 2012, at 1:46 AM, Mark Shannon wrote:
>
> '''
> Being able to pre-allocate lists based on the expected size, as estimated by __length_hint__,
> can be a significant optimization.
> PyPy has been observed to run some code slower than CPython, purely because this optimization is absent.
> '''
>
> Which is a PyPy bug report, not a rationale for a PEP ;)
Alex's rationale is correct and well expressed.
Your proposed revision reflects fuzzy thinking about why __length_hint__ is useful.
Regardless of resizing growth factors, it is *always* helpful to know how much
memory to allocate. Calls to the allocators (especially for large blocks)
and possible the recopying of data should be avoided when possible.
Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From stephen at xemacs.org Thu Aug 2 17:49:28 2012
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 03 Aug 2012 00:49:28 +0900
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the
importlib.PathFinder docs and docstring more in line
In-Reply-To:
References: <3Wns631KFWzPhs@mail.python.org>
<20120802103219.19acba49@resist.wooz.org>
Message-ID: <876291l2ev.fsf@uwakimon.sk.tsukuba.ac.jp>
Chris Jerdonek writes:
> On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote:
> > I find this change hilarious! Is it "an under-under path" or "a
> > dunder path"?
>
> Personally, I just say "path" (same with __init__, __main__, etc) and
> rely on context.
I think that's what the Chicago Manual of Style recommends.
Now-needing-surgery-for-my-cheek-hernia-ly y'rs,
From brett at python.org Thu Aug 2 23:53:46 2012
From: brett at python.org (Brett Cannon)
Date: Thu, 2 Aug 2012 17:53:46 -0400
Subject: [Python-Dev] [Python-checkins] cpython: Update the What's New
details for importlib based on doc/ABC changes.
In-Reply-To: <3Wp4n324DJzPhs@mail.python.org>
References: <3Wp4n324DJzPhs@mail.python.org>
Message-ID:
Sorry about accidentally committing another minor cleanup to importlib in
this commit; thought I had already committed it separately.
On Thu, Aug 2, 2012 at 5:50 PM, brett.cannon wrote:
> http://hg.python.org/cpython/rev/083534cd7874
> changeset: 78388:083534cd7874
> user: Brett Cannon
> date: Thu Aug 02 17:50:06 2012 -0400
> summary:
> Update the What's New details for importlib based on doc/ABC changes.
>
> files:
> Doc/library/importlib.rst | 10 ++++++----
> Doc/whatsnew/3.3.rst | 24 +++++++++++++++++++-----
> 2 files changed, 25 insertions(+), 9 deletions(-)
>
>
> diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst
> --- a/Doc/library/importlib.rst
> +++ b/Doc/library/importlib.rst
> @@ -141,9 +141,10 @@
> longer requires implementation of a ``find_module()`` method.
>
>
> -.. class:: MetaPathFinder(Finder)
> +.. class:: MetaPathFinder
>
> - An abstract base class representing a :term:`meta path finder`.
> + An abstract base class representing a :term:`meta path finder` and
> + inheriting from :class:`Finder`.
>
> .. versionadded:: 3.3
>
> @@ -156,9 +157,10 @@
> package. If a loader cannot be found, ``None`` is returned.
>
>
> -.. class:: PathEntryFinder(Finder)
> +.. class:: PathEntryFinder
>
> - An abstract base class representing a :term:`path entry finder`.
> + An abstract base class representing a :term:`path entry finder` and
> + inheriting from :class:`Finder`.
>
> .. versionadded:: 3.3
>
> diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
> --- a/Doc/whatsnew/3.3.rst
> +++ b/Doc/whatsnew/3.3.rst
> @@ -519,7 +519,15 @@
> making the import statement work. That means the various importers that
> were
> once implicit are now fully exposed as part of the :mod:`importlib`
> package.
>
> -In terms of finders, * :class:`importlib.machinery.FileFinder` exposes the
> +The abstract base classes defined in :mod:`importlib.abc` have been
> expanded
> +to properly delineate between :term:`meta path finders `
> +and :term:`path entry finders ` by introducing
> +:class:`importlib.abc.MetaPathFinder` and
> +:class:`importlib.abc.PathEntryFinder`, respectively. The old ABC of
> +:class:`importlib.abc.Finder` is now only provided for
> backwards-compatibility
> +and does not enforce any method requirements.
> +
> +In terms of finders, :class:`importlib.machinery.FileFinder` exposes the
> mechanism used to search for source and bytecode files of a module.
> Previously
> this class was an implicit member of :attr:`sys.path_hooks`.
>
> @@ -547,10 +555,10 @@
>
> Beyond the expanse of what :mod:`importlib` now exposes, there are other
> visible changes to import. The biggest is that :attr:`sys.meta_path` and
> -:attr:`sys.path_hooks` now store all of the finders used by import
> explicitly.
> -Previously the finders were implicit and hidden within the C code of
> import
> -instead of being directly exposed. This means that one can now easily
> remove or
> -change the order of the various finders to fit one's needs.
> +:attr:`sys.path_hooks` now store all of the meta path finders and path
> entry
> +hooks used by import. Previously the finders were implicit and hidden
> within
> +the C code of import instead of being directly exposed. This means that
> one can
> +now easily remove or change the order of the various finders to fit one's
> needs.
>
> Another change is that all modules have a ``__loader__`` attribute,
> storing the
> loader used to create the module. :pep:`302` has been updated to make this
> @@ -1733,6 +1741,12 @@
> both the modification time and size of the source file the bytecode
> file was
> compiled from.
>
> +* :class:`importlib.abc.Finder` no longer specifies a `find_module()`
> abstract
> + method that must be implemented. If you were relying on subclasses to
> + implement that method, make sure to check for the method's existence
> first.
> + You will probably want to check for `find_loader()` first, though, in
> the
> + case of working with :term:`path entry finders `.
> +
> * :mod:`pkgutil` has been converted to use :mod:`importlib` internally.
> This
> eliminates many edge cases where the old behaviour of the PEP 302 import
> emulation failed to match the behaviour of the real import system. The
>
> --
> Repository URL: http://hg.python.org/cpython
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ncoghlan at gmail.com Fri Aug 3 07:13:50 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 3 Aug 2012 15:13:50 +1000
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the
importlib.PathFinder docs and docstring more in line
In-Reply-To:
References: <3Wns631KFWzPhs@mail.python.org>
<20120802103219.19acba49@resist.wooz.org>
Message-ID:
On Fri, Aug 3, 2012 at 12:41 AM, Chris Jerdonek
wrote:
> On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote:
>> On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote:
>>
>>>-module. Specifically, any module that contains an ``__path__`` attribute is
>>>+module. Specifically, any module that contains a ``__path__`` attribute is
>>
>> I find this change hilarious! Is it "an under-under path" or "a dunder path"?
>
> Personally, I just say "path" (same with __init__, __main__, etc) and
> rely on context.
Yup. That's why I would write "a __path__ attribute", but "an __init__ method".
If I have to be explicit when speaking, I'll typically say either
"dunder " or "double underscore ". I find that's
only needed if there is a name class between the double underscore
name and a non-prefixed variable though, which doesn't happen very
often.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
From dheerajgoswami at yahoo.com Fri Aug 3 20:53:05 2012
From: dheerajgoswami at yahoo.com (Dheeraj Goswami)
Date: Fri, 3 Aug 2012 11:53:05 -0700 (PDT)
Subject: [Python-Dev] Question
Message-ID: <1344019985.56562.YahooMailNeo@web122406.mail.ne1.yahoo.com>
Hi Python Gurus,
I am an experienced Java developer and have been working on it for about 8 years. I need to build a web 2.0/AJAX based website/application and I am thinking to build it in Django which means I need to learn and move to Python.
Please advise is it really worth moving from Java world into Python world? Will it really be fun to build in Django.
PS: I dont like magics so I will never use Ruby/Rails as I am not that kind of guy.
cheers
/Dg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From python at mrabarnett.plus.com Fri Aug 3 21:15:12 2012
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 03 Aug 2012 20:15:12 +0100
Subject: [Python-Dev] Question
In-Reply-To: <1344019985.56562.YahooMailNeo@web122406.mail.ne1.yahoo.com>
References: <1344019985.56562.YahooMailNeo@web122406.mail.ne1.yahoo.com>
Message-ID: <501C2340.1020803@mrabarnett.plus.com>
On 03/08/2012 19:53, Dheeraj Goswami wrote:
> Hi Python Gurus,
> I am an experienced Java developer and have been working on it for about
> 8 years. I need to build a web 2.0/AJAX based website/application and I
> am thinking to build it in Django which means I need to learn and move
> to Python.
>
> Please advise is it really worth moving from Java world into Python
> world? Will it really be fun to build in Django.
>
> PS: I dont like magics so I will never use Ruby/Rails as I am not that
> kind of guy.
>
This list is for the development _of_ Python, not development _with_
Python.
Please post to python-list at python.org instead.
From rosuav at gmail.com Fri Aug 3 21:20:25 2012
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 4 Aug 2012 05:20:25 +1000
Subject: [Python-Dev] Question
In-Reply-To: <1344019985.56562.YahooMailNeo@web122406.mail.ne1.yahoo.com>
References: <1344019985.56562.YahooMailNeo@web122406.mail.ne1.yahoo.com>
Message-ID:
On Sat, Aug 4, 2012 at 4:53 AM, Dheeraj Goswami
wrote:
> Hi Python Gurus,
> I am an experienced Java developer and have been working on it for about 8
> years. I need to build a web 2.0/AJAX based website/application and I am
> thinking to build it in Django which means I need to learn and move to
> Python.
>
> Please advise is it really worth moving from Java world into Python world?
> Will it really be fun to build in Django.
This list is more about the development _of_ Python rather than
development _with_ Python. You'll get more responses on
python-list at python.org instead.
But I would say that yes, it IS worth moving from Java to Python. If
nothing else, learning more languages is always advantageous!
Chris Angelico
From chris.jerdonek at gmail.com Fri Aug 3 22:46:09 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Fri, 3 Aug 2012 13:46:09 -0700
Subject: [Python-Dev] issue 15510: textwrap.wrap() returning empty list
Message-ID:
I would like people's opinions on issue 15510, specifically whether it
should be addressed and in what versions:
http://bugs.python.org/issue15510
Jes?s suggested that I ask. The issue relates to textwrap.wrap()'s
behavior when wrapping strings that contain no non-whitespace
characters -- in particular the empty string.
Thanks,
--Chris
From python at mrabarnett.plus.com Fri Aug 3 23:51:33 2012
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 03 Aug 2012 22:51:33 +0100
Subject: [Python-Dev] issue 15510: textwrap.wrap() returning empty list
In-Reply-To:
References:
Message-ID: <501C47E5.9090600@mrabarnett.plus.com>
On 03/08/2012 21:46, Chris Jerdonek wrote:
> I would like people's opinions on issue 15510, specifically whether it
> should be addressed and in what versions:
>
> http://bugs.python.org/issue15510
>
> Jes?s suggested that I ask. The issue relates to textwrap.wrap()'s
> behavior when wrapping strings that contain no non-whitespace
> characters -- in particular the empty string.
>
If you don't want the empty list, you could just write:
wrap(text) or ['']
From "ja...py" at farowl.co.uk Sat Aug 4 01:34:16 2012
From: "ja...py" at farowl.co.uk (Jeff Allen)
Date: Sat, 04 Aug 2012 00:34:16 +0100
Subject: [Python-Dev] Understanding the buffer API
Message-ID: <501C5FF8.10209@farowl.co.uk>
I'm implementing the buffer API and some of memoryview for Jython. I
have read with interest, and mostly understood, the discussion in Issue
#10181 that led to the v3.3 re-implementation of memoryview and
much-improved documentation of the buffer API. Although Jython is
targeting v2.7 at the moment, and 1-D bytes (there's no Jython NumPy),
I'd like to lay a solid foundation that benefits from the recent CPython
work. I hope that some of the complexity in memoryview stems from legacy
considerations I don't have to deal with in Jython.
I am puzzled that PEP 3118 makes some specifications that seem
unnecessary and complicate the implementation. Would those who know the
API inside out answer a few questions?
My understanding is this: When a consumer requests a buffer from the
exporter it specifies using flags how it intends to navigate it. If the
buffer actually needs more apparatus than the consumer proposes, this
raises an exception. If the buffer needs less apparatus than the
consumer proposes, the exporter has to supply what was asked for. For
example, if the consumer sets PyBUF_STRIDES, and the buffer can only be
navigated by using suboffsets (PIL-style) this raises an exception.
Alternatively, if the consumer sets PyBUF_STRIDES, and the buffer is
just a simple byte array, the exporter has to supply shape and strides
arrays (with trivial values), since the consumer is going to use those
arrays.
Is there any harm is supplying shape and strides when they were not
requested? The PEP says: "PyBUF_ND ... If this is not given then shape
will be NULL". It doesn't stipulate that strides will be null if
PyBUF_STRIDES is not given, but the library documentation says so.
suboffsets is different since even when requested, it will be null if
not needed.
Similar, but simpler, the PEP says "PyBUF_FORMAT ... If format is not
explicitly requested then the format must be returned as NULL (which
means "B", or unsigned bytes)". What would be the harm in returning "B"?
One place where this really matters is in the implementation of
memoryview. PyMemoryView requests a buffer with the flags PyBUF_FULL_RO,
so even a simple byte buffer export will come with shape, strides and
format. A consumer (of the memoryview's buffer API) might specify
PyBUF_SIMPLE: according to the PEP I can't simply give it the original
buffer since required fields (that the consumer will presumably not
access) are not NULL. In practice, I'd like to: what could possibly go
wrong?
Jeff Allen
From stefan at bytereef.org Sat Aug 4 11:11:50 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 4 Aug 2012 11:11:50 +0200
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To: <501C5FF8.10209@farowl.co.uk>
References: <501C5FF8.10209@farowl.co.uk>
Message-ID: <20120804091150.GA12337@sleipnir.bytereef.org>
Jeff Allen wrote:
> I'd like to lay a solid foundation that benefits from the
> recent CPython work. I hope that some of the complexity in
> memoryview stems from legacy considerations I don't have to deal
> with in Jython.
I'm afraid not: PEP-3118 is really that complex. ;)
> My understanding is this: When a consumer requests a buffer from the
> exporter it specifies using flags how it intends to navigate it. If
> the buffer actually needs more apparatus than the consumer proposes,
> this raises an exception. If the buffer needs less apparatus than
> the consumer proposes, the exporter has to supply what was asked
> for. For example, if the consumer sets PyBUF_STRIDES, and the
> buffer can only be navigated by using suboffsets (PIL-style) this
> raises an exception. Alternatively, if the consumer sets
> PyBUF_STRIDES, and the buffer is just a simple byte array, the
> exporter has to supply shape and strides arrays (with trivial
> values), since the consumer is going to use those arrays.
Yes.
> Is there any harm is supplying shape and strides when they were not
> requested? The PEP says: "PyBUF_ND ... If this is not given then
> shape will be NULL". It doesn't stipulate that strides will be null
> if PyBUF_STRIDES is not given, but the library documentation says
> so. suboffsets is different since even when requested, it will be
> null if not needed.
You are right that the PEP does not explicitly state that rule for
strides. However, NULL always has an implied meaning:
format=NULL -> treat the buffer as unsigned bytes.
shape=NULL -> one-dimensional AND treat the buffer as unsigned bytes.
strides=NULL -> C-contiguous
I think relaxing the NULL rule for strides would complicate things,
since it would introduce yet another special case.
> Similar, but simpler, the PEP says "PyBUF_FORMAT ... If format is
> not explicitly requested then the format must be returned as NULL
> (which means "B", or unsigned bytes)". What would be the harm in
> returning "B"?
Ah, yes. The key here is this:
"This would be used when the consumer is going to be checking for what
'kind' of data is actually stored."
Conversely, if not requested, format=NULL indicates that the real
format may be e.g. 'L', but the consumer wants to treat the buffer
as unsigned bytes. This works because the 'len' field stores the
length of the memory area in bytes (for contiguous buffers at least).
The 'itemsize' field may be wrong though in this special case.
In general, format=NULL is a cast of a (possibly multi-dimensional)
C-contiguous buffer to a one-dimensional buffer of unsigned bytes.
IMO only the following combinations make sense. These two are self explanatory:
1) shape=NULL, format=NULL -> e.g. PyBUF_SIMPLE
2) shape!=NULL, format!=NULL -> e.g. PyBUF_FULL
1) can break the invariant product(shape) * itemsize = len!
The next combination exists as part of PyBUF_STRIDED:
3) shape!=NULL, format=NULL.
It can break two invariants (product(shape) * itemsize = len,
calcsize(format) = itemsize), but since it's explicitly part of
PyBUF_STRIDED, memoryview_getbuf() allows it.
The remaining combination is disallowed, since the buffer is already assumed to
be unsigned bytes:
4) shape=NULL, format!=NULL.
> One place where this really matters is in the implementation of
> memoryview. PyMemoryView requests a buffer with the flags
> PyBUF_FULL_RO, so even a simple byte buffer export will come with
> shape, strides and format. A consumer (of the memoryview's buffer
> API) might specify PyBUF_SIMPLE: according to the PEP I can't simply
> give it the original buffer since required fields (that the consumer
> will presumably not access) are not NULL. In practice, I'd like to:
> what could possibly go wrong?
Because of all the implied meanings of NULL, I think the safest way is
to implement memoryview_getbuf() for Jython. After all the PEP describes
a protocol, so everyone should really be doing the same thing.
Whether the protocol needs to be that complex is another question.
Partially initialized buffers are a pain to handle on the C level
since it is necessary to reconstruct the missing values -- at least if
you want to keep your sanity :).
I think the protocol would benefit from changing the getbuffer rules to:
a) The buffer gets a 'flags' field that can store properties like
PyBUF_SIMPLE, PyBUF_C_CONTIGUOUS etc.
b) The exporter must *always* provide full information.
c) If a buffer can be exported as unsigned bytes but has a different
layout, the exporter must perform a full cast so that the above
mentioned invariants are kept.
The disadvantage of this is that the original layout is lost for
the consumer. I do not know if there is a use case that requires
the consumer to have the original layout information.
Stefan Krah
From "ja...py" at farowl.co.uk Sat Aug 4 15:48:47 2012
From: "ja...py" at farowl.co.uk (Jeff Allen)
Date: Sat, 04 Aug 2012 14:48:47 +0100
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To: <20120804091150.GA12337@sleipnir.bytereef.org>
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
Message-ID: <501D283F.9050207@farowl.co.uk>
Thanks for a swift reply: you're just the person I hoped would do so.
On 04/08/2012 10:11, Stefan Krah wrote:
> You are right that the PEP does not explicitly state that rule for
> strides. However, NULL always has an implied meaning:
>
> format=NULL -> treat the buffer as unsigned bytes.
>
> shape=NULL -> one-dimensional AND treat the buffer as unsigned bytes.
>
> strides=NULL -> C-contiguous
>
> I think relaxing the NULL rule for strides would complicate things,
> since it would introduce yet another special case.
... Ok, I think I see that how the absence of certain arrays is used to
deduce structural simplicity, over and above their straightforward use
in navigating the data. So although no shape array is (sort of)
equivalent to ndim==1, shape[0]==len, it also means I can call simpler
code instead of using the arrays for navigation.
I still don't see why, if the consumer says "I'm assuming 1-D unsigned
bytes", and that's what the data is, memoryview_getbuf could not provide
a shape and strides that agree with the data. Is the catch perhaps that
there is code (in abstract.c etc.) that does not know what the consumer
promised not to use/look at? Would it actually break, e.g. not treat it
as bytes, or just be inefficient?
> Because of all the implied meanings of NULL, I think the safest way is
> to implement memoryview_getbuf() for Jython. After all the PEP describes
> a protocol, so everyone should really be doing the same thing.
I'll look carefully at what you've written (snipped here) because it is
these "consumer expectations" that are most important. The Jython buffer
API is necessarily a lot different from the C one: some things are not
possible in Java (pointer arithmetic) and some are just un-Javan
activities (allocate a struct and have the library fill it in). I'm only
going for a logical conformance to the PEP: the same navigational and
other attributes, that mean the same things for the consumer.
When you say such-and-such is disallowed, but the PEP or the data
structures seem to provide for it, you mean memoryview_getbuf()
disallows it, since you've concluded it is not sensible?
> I think the protocol would benefit from changing the getbuffer rules to:
>
> a) The buffer gets a 'flags' field that can store properties like
> PyBUF_SIMPLE, PyBUF_C_CONTIGUOUS etc.
>
> b) The exporter must *always* provide full information.
>
> c) If a buffer can be exported as unsigned bytes but has a different
> layout, the exporter must perform a full cast so that the above
> mentioned invariants are kept.
>
Just like PyManagedBuffer mbuf and its sister view in memoryview? I've
thought the same things, but the tricky part is to do it compatibly.
a) I think I can achieve this. As I have interfaces and polymorphism on
my side, and a commitment only to logical equivalence to CPython, I can
have the preserved flags stashed away inside to affect behaviour. But
it's not as simple as saving the consumer's request, and I'm still
trying to work it out what to do, e.g. when the consumer didn't ask for
C-contiguity, but in this case it happens to be true.
In the same way, functions you have in abstract.c etc. can be methods
that, rather than work out by inspection of a struct how to navigate the
data on this call, already know what kind of buffer they are in. So
SimpleBuffer.isContiguous(char order) can simply return true.
b) What I'm hoping can work, but maybe not.
c) Java will not of course give you raw memory it thinks is one thing,
to treat as another, so this aspect is immature in my thinking. I got as
far as accommodating multi-byte items, but have no use for them as yet.
Thanks again for the chance to test my ideas.
Jeff Allen
From ncoghlan at gmail.com Sat Aug 4 16:51:06 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 5 Aug 2012 00:51:06 +1000
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To: <20120804091150.GA12337@sleipnir.bytereef.org>
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
Message-ID:
On Sat, Aug 4, 2012 at 7:11 PM, Stefan Krah wrote:
> You are right that the PEP does not explicitly state that rule for
> strides. However, NULL always has an implied meaning:
>
> format=NULL -> treat the buffer as unsigned bytes.
>
> shape=NULL -> one-dimensional AND treat the buffer as unsigned bytes.
>
> strides=NULL -> C-contiguous
>
>
> I think relaxing the NULL rule for strides would complicate things,
> since it would introduce yet another special case.
I took Jeff's question as being slightly different and applying in the
following situations:
1. If the consumer has NOT requested format data, can the provider
return accurate format data anyway, if that's easier than returning
NULL but is consistent with doing so?
2. The consumer has NOT requested shape data, can shape data be
provided anyway, if that's easier than returning NULL but is
consistent with doing so?
3. The consumer has NOT requested strides data, can strides data be
provided anyway, if that's easier than returning NULL but is
consistent with doing so?
That's what I believe is Jeff's main question: is a provider that
always publishes complete information, even if the consumer doesn't
ask for it, in compliance with the API, so long as any cases where the
consumer's stated assumption (as indicated by the request flags) would
be violated are handled as errors instead of successfully populating
the buffer?
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
From stefan at bytereef.org Sat Aug 4 17:25:49 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 4 Aug 2012 17:25:49 +0200
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To: <501D283F.9050207@farowl.co.uk>
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
<501D283F.9050207@farowl.co.uk>
Message-ID: <20120804152549.GA16358@sleipnir.bytereef.org>
Jeff Allen wrote:
> I still don't see why, if the consumer says "I'm assuming 1-D
> unsigned bytes", and that's what the data is, memoryview_getbuf
> could not provide a shape and strides that agree with the data.
In most cases it won't matter. However, a consumer is entitled to rely
on shape==NULL in response to a PyBUF_SIMPLE request. Perhaps there
is code that tests for shape==NULL to determine C-contiguity.
This is an example that might occur in C. You hinted at the fact that not
all of this may be relevant for Java, but on that I can't comment.
> When you say such-and-such is disallowed, but the PEP or the data
> structures seem to provide for it, you mean memoryview_getbuf()
> disallows it, since you've concluded it is not sensible?
The particular request of PyBUF_SIMPLE|PyBUF_FORMAT, when applied to
any array that is not one-dimensional with format 'B' would lead to a
contradiction: PyBUF_SIMPLE implies 'B', but format would be set to
something else.
It is also a useless combination, since a plain PyBUF_SIMPLE suffices.
> >I think the protocol would benefit from changing the getbuffer rules to:
> >
> > a) The buffer gets a 'flags' field that can store properties like
> > PyBUF_SIMPLE, PyBUF_C_CONTIGUOUS etc.
> >
> > b) The exporter must *always* provide full information.
> >
> > c) If a buffer can be exported as unsigned bytes but has a different
> > layout, the exporter must perform a full cast so that the above
> > mentioned invariants are kept.
> >
> Just like PyManagedBuffer mbuf and its sister view in memoryview?
> I've thought the same things, but the tricky part is to do it
> compatibly.
>
> a) I think I can achieve this. As I have interfaces and polymorphism
> on my side, and a commitment only to logical equivalence to CPython,
> I can have the preserved flags stashed away inside to affect
> behaviour. But it's not as simple as saving the consumer's request,
> and I'm still trying to work it out what to do, e.g. when the
> consumer didn't ask for C-contiguity, but in this case it happens to
> be true.
>
> In the same way, functions you have in abstract.c etc. can be
> methods that, rather than work out by inspection of a struct how to
> navigate the data on this call, already know what kind of buffer
> they are in. So SimpleBuffer.isContiguous(char order) can simply
> return true.
Avoiding repeated calls to PyBuffer_IsContiguous() was in fact the main
reason for storing flags in the new MemoryViewObject.
It would be handy to have these flags in the Py_buffer structure, but
that can only be considered for a future version of Python, perhaps no
earlier than 4.0. The same applies of course to all three points that
I made above.
Stefan Krah
From storchaka at gmail.com Sat Aug 4 17:25:40 2012
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 04 Aug 2012 18:25:40 +0300
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To:
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
Message-ID:
On 04.08.12 17:51, Nick Coghlan wrote:
> I took Jeff's question as being slightly different and applying in the
> following situations:
>
> 1. If the consumer has NOT requested format data, can the provider
> return accurate format data anyway, if that's easier than returning
> NULL but is consistent with doing so?
>
> 2. The consumer has NOT requested shape data, can shape data be
> provided anyway, if that's easier than returning NULL but is
> consistent with doing so?
>
> 3. The consumer has NOT requested strides data, can strides data be
> provided anyway, if that's easier than returning NULL but is
> consistent with doing so?
4. The consumer has NOT requested writable buffer, can readonly flag of
provided buffer be false anyway?
From ncoghlan at gmail.com Sat Aug 4 17:35:00 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 5 Aug 2012 01:35:00 +1000
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To: <20120804152549.GA16358@sleipnir.bytereef.org>
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
<501D283F.9050207@farowl.co.uk>
<20120804152549.GA16358@sleipnir.bytereef.org>
Message-ID:
On Sun, Aug 5, 2012 at 1:25 AM, Stefan Krah wrote:
> In most cases it won't matter. However, a consumer is entitled to rely
> on shape==NULL in response to a PyBUF_SIMPLE request. Perhaps there
> is code that tests for shape==NULL to determine C-contiguity.
>
> This is an example that might occur in C. You hinted at the fact that not
> all of this may be relevant for Java, but on that I can't comment.
Think about trying to specify the buffer protocol using only C++
references rather than pointers. In Java, it's a lot easier to say
"this value must be a reference to 'B'" than it is to say "this value
must be NULL". (My Java is a little rusty, but I'm still pretty sure
you can only get NullPointerException by messing about with the JNI).
I think it's worth defining an "OR" clause for each of the current "X
must be NULL" cases, where it is legal for the provider to emit an
appropriate non-NULL value that would be consistent with the consumer
assuming that the returned value is consistent with what they
requested.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
From stefan at bytereef.org Sat Aug 4 17:39:17 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 4 Aug 2012 17:39:17 +0200
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To:
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
Message-ID: <20120804153916.GA16584@sleipnir.bytereef.org>
Nick Coghlan wrote:
> I took Jeff's question as being slightly different and applying in the
> following situations:
I think I attempted to answer the same thing. :)
> 1. If the consumer has NOT requested format data, can the provider
> return accurate format data anyway, if that's easier than returning
> NULL but is consistent with doing so?
No, this is definitely disallowed by the PEP (PyBUF_FORMAT):
"If format is not explicitly requested then the format must be returned as
NULL (which means "B", or unsigned bytes)."
> 2. The consumer has NOT requested shape data, can shape data be
> provided anyway, if that's easier than returning NULL but is
> consistent with doing so?
Also explicitly disallowed (PyBUF_ND):
"If this is not given then shape will be NULL."
> 3. The consumer has NOT requested strides data, can strides data be
> provided anyway, if that's easier than returning NULL but is
> consistent with doing so?
This is not explicitly disallowed, but IMO the intent is that strides
should also be NULL in that case. For example, strides==NULL might be
used for a quick C-contiguity test.
Stefan Krah
From chris.jerdonek at gmail.com Sat Aug 4 17:41:33 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Sat, 4 Aug 2012 08:41:33 -0700
Subject: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default):
Make TextIOWrapper's documentation clearer by copying the newline
argument's
In-Reply-To: <3WpkGy3N7VzPgX@mail.python.org>
References: <3WpkGy3N7VzPgX@mail.python.org>
Message-ID:
On Fri, Aug 3, 2012 at 3:59 PM, antoine.pitrou
wrote:
> http://hg.python.org/cpython/rev/f17a1410ebe5
> changeset: 78401:f17a1410ebe5
> summary:
> Make TextIOWrapper's documentation clearer by copying the newline argument's description from open().
Now that this change is made, it may make sense to update the
subprocess documentation to reference TextIOWrapper's documentation
instead of open()'s (since use of the 'U' flag to open() is
discouraged in new code).
"All line endings will be converted to '\n' as described for the
universal newlines 'U' mode argument to open()."
(from http://docs.python.org/dev/library/subprocess.html#frequently-used-arguments
)
--Chris
From stefan at bytereef.org Sat Aug 4 17:43:58 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 4 Aug 2012 17:43:58 +0200
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To:
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
Message-ID: <20120804154358.GB16584@sleipnir.bytereef.org>
Serhiy Storchaka wrote:
> 4. The consumer has NOT requested writable buffer, can readonly flag
> of provided buffer be false anyway?
Yes, per the new documentation. This is not explicitly mentioned in the PEP
but was existing practice and greatly simplifies several things:
http://docs.python.org/dev/c-api/buffer.html#PyBUF_WRITABLE
Stefan Krah
From stefan at bytereef.org Sat Aug 4 18:41:40 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 4 Aug 2012 18:41:40 +0200
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To:
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
<501D283F.9050207@farowl.co.uk>
<20120804152549.GA16358@sleipnir.bytereef.org>
Message-ID: <20120804164140.GA16845@sleipnir.bytereef.org>
Nick Coghlan wrote:
> Think about trying to specify the buffer protocol using only C++
> references rather than pointers. In Java, it's a lot easier to say
> "this value must be a reference to 'B'" than it is to say "this value
> must be NULL". (My Java is a little rusty, but I'm still pretty sure
> you can only get NullPointerException by messing about with the JNI).
>
> I think it's worth defining an "OR" clause for each of the current "X
> must be NULL" cases, where it is legal for the provider to emit an
> appropriate non-NULL value that would be consistent with the consumer
> assuming that the returned value is consistent with what they
> requested.
I think any implementation that doesn't use the Py_buffer struct directly
in a C-API should just always return a full buffer if a specific request
can be met according to the rules.
For the C-API, I would be cautious:
- The number of case splits in testing getbuffer flags is already
staggering. Defining an "OR" clause would introduce new cases.
- Consumers may simply rely on the status-quo.
As I said in my earlier mail, for Python 4.0, I'd rather see that buffers
have mandatory full information. Querying individual Py_buffer fields for
NULL should be replaced by a set of flags that would determine contiguity,
buffer "history" (has the buffer been cast to unsigned bytes?) etc.
It would also be possible to add new flags for things like byte order.
The main reason is that it turns out that in any general C function that
takes a Py_buffer argument one has to reconstruct full information anyway,
otherwise obscure cases *will* be overlooked (in the absence of a formal
proof that takes care of all case splits).
Stefan Krah
From ncoghlan at gmail.com Sat Aug 4 19:13:48 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 5 Aug 2012 03:13:48 +1000
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To: <20120804164140.GA16845@sleipnir.bytereef.org>
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
<501D283F.9050207@farowl.co.uk>
<20120804152549.GA16358@sleipnir.bytereef.org>
<20120804164140.GA16845@sleipnir.bytereef.org>
Message-ID:
On Sun, Aug 5, 2012 at 2:41 AM, Stefan Krah wrote:
> Nick Coghlan wrote:
>> Think about trying to specify the buffer protocol using only C++
>> references rather than pointers. In Java, it's a lot easier to say
>> "this value must be a reference to 'B'" than it is to say "this value
>> must be NULL". (My Java is a little rusty, but I'm still pretty sure
>> you can only get NullPointerException by messing about with the JNI).
>>
>> I think it's worth defining an "OR" clause for each of the current "X
>> must be NULL" cases, where it is legal for the provider to emit an
>> appropriate non-NULL value that would be consistent with the consumer
>> assuming that the returned value is consistent with what they
>> requested.
>
> I think any implementation that doesn't use the Py_buffer struct directly
> in a C-API should just always return a full buffer if a specific request
> can be met according to the rules.
Since Jeff is talking about an inspired-by API, rather than using the
C API directly, I think that's the way Jython should go: *require*
that those fields be populated appropriately, rather than allowing
them to be None.
> For the C-API, I would be cautious:
>
> - The number of case splits in testing getbuffer flags is already
> staggering. Defining an "OR" clause would introduce new cases.
>
> - Consumers may simply rely on the status-quo.
>
>
> As I said in my earlier mail, for Python 4.0, I'd rather see that buffers
> have mandatory full information. Querying individual Py_buffer fields for
> NULL should be replaced by a set of flags that would determine contiguity,
> buffer "history" (has the buffer been cast to unsigned bytes?) etc.
Making a switch to mandatory full information later suggest that we
need to at least make it optional now. I do agree with what you
suggest though, which is that, if a buffer chooses to always publish
full and accurate information it must do so for *all* fields.Tthat
should reduce the combinatorial explosion.
It does place a constraint on consumers that they can't assume those
fields will be NULL just because they didn't ask for them, but I'm
struggling to think of any reason why a client would actually *check*
that instead of just assuming it. I guess the dodgy Py_buffer-copying
code in the old memoryview implementation only mostly works because
those fields are almost always NULL, but that approach was just deeply
broken in general.
> The main reason is that it turns out that in any general C function that
> takes a Py_buffer argument one has to reconstruct full information anyway,
> otherwise obscure cases *will* be overlooked (in the absence of a formal
> proof that takes care of all case splits).
Right, that's why I think we should declare it legal to *provide* full
information even if the consumer didn't ask for it, *as long as* any
consumer assumptions implied by the limited request (such as unsigned
byte data, a single dimension or C contiguity) remain valid. Consumers
that can't handle that correctly (which would likely include the
pre-3.3 memoryview) are officially broken.
As you say, we likely can't make providing full information mandatory
during the 3.x cycle, but we can at least pave the way for it.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
From victor.stinner at gmail.com Sat Aug 4 20:51:58 2012
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sat, 4 Aug 2012 20:51:58 +0200
Subject: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default):
Make TextIOWrapper's documentation clearer by copying the newline
argument's
In-Reply-To:
References: <3WpkGy3N7VzPgX@mail.python.org>
Message-ID:
2012/8/4 Chris Jerdonek :
> On Fri, Aug 3, 2012 at 3:59 PM, antoine.pitrou
> wrote:
>> http://hg.python.org/cpython/rev/f17a1410ebe5
>> changeset: 78401:f17a1410ebe5
>> summary:
>> Make TextIOWrapper's documentation clearer by copying the newline argument's description from open().
>
> Now that this change is made, it may make sense to update the
> subprocess documentation to reference TextIOWrapper's documentation
> instead of open()'s (since use of the 'U' flag to open() is
> discouraged in new code).
>
> "All line endings will be converted to '\n' as described for the
> universal newlines 'U' mode argument to open()."
>
> (from http://docs.python.org/dev/library/subprocess.html#frequently-used-arguments
> )
Good idea, can you please open an issue? The documentation is wrong:
UTF-8 is not used, it's the locale encoding.
Victor
From "ja...py" at farowl.co.uk Sun Aug 5 12:08:58 2012
From: "ja...py" at farowl.co.uk (Jeff Allen)
Date: Sun, 05 Aug 2012 11:08:58 +0100
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To:
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
<501D283F.9050207@farowl.co.uk>
<20120804152549.GA16358@sleipnir.bytereef.org>
<20120804164140.GA16845@sleipnir.bytereef.org>
Message-ID: <501E463A.9090200@farowl.co.uk>
- Summary:
The PEP, or sometimes just the documentation, definitely requires that
features not requested shall be NULL.
The API would benefit from:
a. stored flags that tell you the actual structural features.
b. requiring exporters to provide full information (e.g. strides =
{1}, format = "B") even when trivial.
It could and possibly should work this way in Python 4.0.
Nick thinks we could *allow* exporters to behave this way (PEP change)
in Python 3.x. Stefan thinks not, because "Perhaps there is code that
tests for shape==NULL to determine C-contiguity."
Jython exporters should return full information unconditionally from the
start: "any implementation that doesn't use the Py_buffer struct
directly in a C-API should just always return a full buffer" (Stefan);
"I think that's the way Jython should go: *require* that those fields be
populated appropriately" (Nick).
- But what I now think is:
_If the only problem really is_ "code that tests for shape==NULL to
determine C-contiguity", or makes similar deductions, I agree that
providing unasked-for information is_safe_. I think the stipulation in
PEP/documentation has some efficiency value: on finding shape!=NULL the
code has to do a more complicated test, as inPyBuffer_IsContiguous(). I
have the option to provide an isContiguous that has the answer written
down already, so the risk is only from/to ported code. If it is only a
risk to the efficiency of ported code, I'm relaxed: I hesitate only to
check that there's no circumstance that logically requires nullity for
correctness. Whether it was safe that was the key question.
In the hypothetical Python 4.0 buffer API (and in Jython) where feature
flags are provided, the efficiency is still useful, but complicated
deductive logic in the consumer should be deprecated in favour of
(functions for) interrogating the flags.
An example illustrating the semantics would then be:
1. consumer requests a buffer, saying "I can cope with a strided arrays"
(PyBUF_STRIDED);
2. exporter provides a strides array, but in the feature flags
STRIDED=0, meaning "you don't need the strides array";
3. exporter (optionally) uses efficient, non-strided access.
_I do not think_ that full provision by the exporter has to be
_mandatory_, as the discussion has gone on to suggest. I know your
experience is that you have often had to regenerate the missing
information to write generic code, but I think this does not continue
once you have the feature flags. An example would be:
1. consumer requests a buffer, saying "I can cope with a N-dimensional
but not strided arrays" (PyBUF_ND);
2. exporter sets strides=NULL, and the feature flag STRIDED=0;
3. exporter accesses the data, without reference to the strides array,
as it planned;
4. new generic code that respects the feature flag STRIDED=0, does not
reference the strides array;
5. old generic code, ignorant of the feature flags, finds the
strides=NULL and so does not dereference strides.
Insofar as it is not necessary, there is some efficiency in not
providing it. There would only be a problem with broken code that both
ignores the feature flag and uses the strides array unchecked. But this
code was always broken.
Really useful discussion this.
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From solipsis at pitrou.net Sun Aug 5 15:00:04 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 5 Aug 2012 15:00:04 +0200
Subject: [Python-Dev] cpython: Close #15559: Implementing __index__
creates a nasty interaction with the bytes
References: <3WqZgS2zn9zPkY@mail.python.org>
Message-ID: <20120805150004.6e38ffdc@pitrou.net>
On Sun, 5 Aug 2012 10:20:36 +0200 (CEST)
nick.coghlan wrote:
> http://hg.python.org/cpython/rev/5abea8a43f19
> changeset: 78426:5abea8a43f19
> user: Nick Coghlan
> date: Sun Aug 05 18:20:17 2012 +1000
> summary:
> Close #15559: Implementing __index__ creates a nasty interaction with the bytes constructor. At least for 3.3, ipaddress objects must now be explicitly converted with int() and thus can't be passed directly to the hex() builtin.
__index__, as the name implies, allows instances to be used as sequence
indices, which does sound like a weird thing to serve as for an IP
address :-)
Regards
Antoine.
--
Software development and contracting: http://pro.pitrou.net
From ncoghlan at gmail.com Sun Aug 5 15:42:38 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 5 Aug 2012 23:42:38 +1000
Subject: [Python-Dev] cpython: Close #15559: Implementing __index__
creates a nasty interaction with the bytes
In-Reply-To: <20120805150004.6e38ffdc@pitrou.net>
References: <3WqZgS2zn9zPkY@mail.python.org>
<20120805150004.6e38ffdc@pitrou.net>
Message-ID:
On Sun, Aug 5, 2012 at 11:00 PM, Antoine Pitrou wrote:
> On Sun, 5 Aug 2012 10:20:36 +0200 (CEST)
> nick.coghlan wrote:
>
>> http://hg.python.org/cpython/rev/5abea8a43f19
>> changeset: 78426:5abea8a43f19
>> user: Nick Coghlan
>> date: Sun Aug 05 18:20:17 2012 +1000
>> summary:
>> Close #15559: Implementing __index__ creates a nasty interaction with the bytes constructor. At least for 3.3, ipaddress objects must now be explicitly converted with int() and thus can't be passed directly to the hex() builtin.
I noticed this when I tried
"bytes(ipaddress.Ipv4Address('192.168.0.1')" Apparently allocating and
initialising a 3.2 GB array on an ASUS Zenbook consumes large amounts
of time and makes the X server rather unresponsive. Even
faulthandler's timeout thread took more than ten times the specified
timeout to actually kill the operation. Who knew? :)
> __index__, as the name implies, allows instances to be used as sequence
> indices, which does sound like a weird thing to serve as for an IP
> address :-)
I expect the original reasoning had to do with the hex() builtin. In
2.x you could selectively support that by implementing __hex__
directly. In 3.x, the __oct__ and __hex__ methods are gone and the
only way to support those builtins (as well as bin()) is by
implementing __index__ instead. However, implementing __index__ makes
the type usable in a whole host of other contexts as well, so the
naive __hex__ -> __index__ conversion really wasn't a good idea.
I'm thinking it may make sense to eventually implement __bytes__, as
having bytes(address) be equivalent to address.packed *does* make
sense. No hurry on that, though.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
From chris.jerdonek at gmail.com Sun Aug 5 17:55:10 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Sun, 5 Aug 2012 08:55:10 -0700
Subject: [Python-Dev] [Python-checkins] devguide: It has been pointed
out this paragraph was incorrect. One of the Windows devs
In-Reply-To: <3WqbHw6rP5zPl0@mail.python.org>
References: <3WqbHw6rP5zPl0@mail.python.org>
Message-ID:
On Sun, Aug 5, 2012 at 1:48 AM, nick.coghlan wrote:
> http://hg.python.org/devguide/rev/f518f23d06d5
> changeset: 539:f518f23d06d5
> summary:
> It has been pointed out this paragraph was incorrect. One of the Windows devs will need to fill in more accurate info
> diff --git a/setup.rst b/setup.rst
> -For Windows systems, all the necessary components should be included in the
> -CPython checkout.
This issue may not provide the information you're looking for, but it
is related:
http://bugs.python.org/issue14873
It has a patch from a few days ago awaiting review.
Incidentally, the UNIX-specific information added in
http://hg.python.org/devguide/rev/80358cdac0a6
might be good to link to in the UNIX section here:
"Do take note of what modules were not built as stated at the end of
your build. More than likely you are missing a dependency for the
module(s) that were not built, and so you can install the dependencies
and re-run both configure and make (if available for your OS)."
(from http://docs.python.org/devguide/setup.html#unix )
Or else move the UNIX-specific information into a subsection of the
UNIX section.
--Chris
From chris.jerdonek at gmail.com Sun Aug 5 21:56:38 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Sun, 5 Aug 2012 12:56:38 -0700
Subject: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default):
Make TextIOWrapper's documentation clearer by copying the newline
argument's
In-Reply-To:
References: <3WpkGy3N7VzPgX@mail.python.org>
Message-ID:
On Sat, Aug 4, 2012 at 11:51 AM, Victor Stinner
wrote:
> 2012/8/4 Chris Jerdonek :
>> Now that this change is made, it may make sense to update the
>> subprocess documentation to reference TextIOWrapper's documentation
>> instead of open()'s (since use of the 'U' flag to open() is
>> discouraged in new code).
>
> Good idea, can you please open an issue? The documentation is wrong:
> UTF-8 is not used, it's the locale encoding.
I created an issue for this (with patch) here:
http://bugs.python.org/issue15561
--Chris
From breamoreboy at yahoo.co.uk Mon Aug 6 00:31:01 2012
From: breamoreboy at yahoo.co.uk (Mark Lawrence)
Date: Sun, 05 Aug 2012 23:31:01 +0100
Subject: [Python-Dev] No summary of tracker issues this week?
Message-ID:
Hi all,
I keep an eye open for this but can't find one for Saturday 03/08/2012.
Have I missed it, has it been stopped, has something gone wrong with
its production or what?
--
Cheers.
Mark Lawrence.
From python at mrabarnett.plus.com Mon Aug 6 01:39:22 2012
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 06 Aug 2012 00:39:22 +0100
Subject: [Python-Dev] No summary of tracker issues this week?
In-Reply-To:
References:
Message-ID: <501F042A.6010702@mrabarnett.plus.com>
On 05/08/2012 23:31, Mark Lawrence wrote:
> Hi all,
>
> I keep an eye open for this but can't find one for Saturday 03/08/2012.
> Have I missed it, has it been stopped, has something gone wrong with
> its production or what?
>
I haven't seen it either.
From status at bugs.python.org Mon Aug 6 03:25:02 2012
From: status at bugs.python.org (Python tracker)
Date: Mon, 6 Aug 2012 03:25:02 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20120806012502.3EAA41CC04@psf.upfronthosting.co.za>
ACTIVITY SUMMARY (2012-07-30 - 2012-08-06)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open 3559 (+18)
closed 23781 (+51)
total 27340 (+69)
Open issues with patches: 1534
Issues opened (42)
==================
#13072: Getting a buffer from a Unicode array uses invalid format
http://bugs.python.org/issue13072 reopened by haypo
#15494: Move test/support.py into a test.support subpackage
http://bugs.python.org/issue15494 opened by cjerdonek
#15495: enable type truncation warnings for gcc builds
http://bugs.python.org/issue15495 opened by jkloth
#15496: harden directory removal for tests on Windows
http://bugs.python.org/issue15496 opened by jkloth
#15497: correct characters in TextWrapper.replace_whitespace docs
http://bugs.python.org/issue15497 opened by cjerdonek
#15498: Eliminate the use of deprecated OS X APIs in getpath.c
http://bugs.python.org/issue15498 opened by ned.deily
#15500: Python should support naming threads
http://bugs.python.org/issue15500 opened by bra
#15501: Document exception classes in subprocess module
http://bugs.python.org/issue15501 opened by anton.barkovsky
#15502: Meta path finders and path entry finders are different, but sh
http://bugs.python.org/issue15502 opened by ncoghlan
#15504: pickle/cPickle saves invalid/incomplete data
http://bugs.python.org/issue15504 opened by Philipp.Lies
#15505: unittest.installHandler incorrectly assumes SIGINT handler is
http://bugs.python.org/issue15505 opened by twouters
#15506: configure should use PKG_PROG_PKG_CONFIG
http://bugs.python.org/issue15506 opened by vapier
#15507: test_subprocess assumes SIGINT is not being ignored.
http://bugs.python.org/issue15507 opened by twouters
#15509: webbrowser.open sometimes passes zero-length argument to the b
http://bugs.python.org/issue15509 opened by anton.barkovsky
#15510: textwrap.wrap('') returns empty list
http://bugs.python.org/issue15510 opened by cjerdonek
#15511: _decimal does not build in PGUpdate mode
http://bugs.python.org/issue15511 opened by skrah
#15513: Correct __sizeof__ support for pickle
http://bugs.python.org/issue15513 opened by storchaka
#15516: exception-handling bug in PyString_Format
http://bugs.python.org/issue15516 opened by tromey
#15518: Provide test coverage for filecmp.dircmp.report methods.
http://bugs.python.org/issue15518 opened by cbc
#15520: Document datetime.timestamp() in 3.3 What's New
http://bugs.python.org/issue15520 opened by djc
#15522: impove 27 percent performance on stringpbject.c( by prefetch a
http://bugs.python.org/issue15522 opened by abael
#15523: Block on close TCP socket in SocketServer.py
http://bugs.python.org/issue15523 opened by jarvisliang
#15526: regrtest crash on Windows 7 AMD64
http://bugs.python.org/issue15526 opened by ncoghlan
#15527: Double parens in functions references
http://bugs.python.org/issue15527 opened by storchaka
#15528: Better support for finalization with weakrefs
http://bugs.python.org/issue15528 opened by sbt
#15533: subprocess.Popen(cwd) documentation
http://bugs.python.org/issue15533 opened by cjerdonek
#15535: Fix pickling of named tuples in 2.7.3
http://bugs.python.org/issue15535 opened by thomie
#15539: Fixing Tools/scripts/pindent.py
http://bugs.python.org/issue15539 opened by storchaka
#15542: Documentation incorrectly suggests __init__ called after direc
http://bugs.python.org/issue15542 opened by Aaron.Staley
#15543: central documentation for 'universal newlines'
http://bugs.python.org/issue15543 opened by cjerdonek
#15544: math.isnan fails with some Decimal NaNs
http://bugs.python.org/issue15544 opened by stevenjd
#15545: sqlite3.Connection.iterdump() does not work with row_factory =
http://bugs.python.org/issue15545 opened by plemarre
#15548: Mention all new os functions in What's New in Python 3.3
http://bugs.python.org/issue15548 opened by haypo
#15549: openssl version in windows builds does not support renegotiati
http://bugs.python.org/issue15549 opened by cory.mintz
#15550: Trailing white spaces
http://bugs.python.org/issue15550 opened by storchaka
#15552: gettext: if looking for .mo in default locations, also look in
http://bugs.python.org/issue15552 opened by Dominique.Leuenberger
#15553: Segfault in test_6_daemon_threads() of test_threading, on Mac
http://bugs.python.org/issue15553 opened by haypo
#15554: correct and clarify str.splitlines() documentation
http://bugs.python.org/issue15554 opened by cjerdonek
#15555: Default newlines of io.TextIOWrapper
http://bugs.python.org/issue15555 opened by ishimoto
#15556: os.stat fails for file pending delete on Windows
http://bugs.python.org/issue15556 opened by jkloth
#15557: Tests for webbrowser module
http://bugs.python.org/issue15557 opened by anton.barkovsky
#15561: update subprocess docs to reference io.TextIOWrapper
http://bugs.python.org/issue15561 opened by cjerdonek
Most recent 15 issues with no replies (15)
==========================================
#15561: update subprocess docs to reference io.TextIOWrapper
http://bugs.python.org/issue15561
#15557: Tests for webbrowser module
http://bugs.python.org/issue15557
#15553: Segfault in test_6_daemon_threads() of test_threading, on Mac
http://bugs.python.org/issue15553
#15552: gettext: if looking for .mo in default locations, also look in
http://bugs.python.org/issue15552
#15549: openssl version in windows builds does not support renegotiati
http://bugs.python.org/issue15549
#15535: Fix pickling of named tuples in 2.7.3
http://bugs.python.org/issue15535
#15533: subprocess.Popen(cwd) documentation
http://bugs.python.org/issue15533
#15527: Double parens in functions references
http://bugs.python.org/issue15527
#15523: Block on close TCP socket in SocketServer.py
http://bugs.python.org/issue15523
#15506: configure should use PKG_PROG_PKG_CONFIG
http://bugs.python.org/issue15506
#15501: Document exception classes in subprocess module
http://bugs.python.org/issue15501
#15497: correct characters in TextWrapper.replace_whitespace docs
http://bugs.python.org/issue15497
#15485: CROSS: append gcc library search paths
http://bugs.python.org/issue15485
#15483: CROSS: initialise include and library paths in setup.py
http://bugs.python.org/issue15483
#15480: Drop TYPE_INT64 from marshal in Python 3.4
http://bugs.python.org/issue15480
Most recent 15 issues waiting for review (15)
=============================================
#15561: update subprocess docs to reference io.TextIOWrapper
http://bugs.python.org/issue15561
#15557: Tests for webbrowser module
http://bugs.python.org/issue15557
#15554: correct and clarify str.splitlines() documentation
http://bugs.python.org/issue15554
#15552: gettext: if looking for .mo in default locations, also look in
http://bugs.python.org/issue15552
#15550: Trailing white spaces
http://bugs.python.org/issue15550
#15548: Mention all new os functions in What's New in Python 3.3
http://bugs.python.org/issue15548
#15544: math.isnan fails with some Decimal NaNs
http://bugs.python.org/issue15544
#15539: Fixing Tools/scripts/pindent.py
http://bugs.python.org/issue15539
#15535: Fix pickling of named tuples in 2.7.3
http://bugs.python.org/issue15535
#15528: Better support for finalization with weakrefs
http://bugs.python.org/issue15528
#15518: Provide test coverage for filecmp.dircmp.report methods.
http://bugs.python.org/issue15518
#15513: Correct __sizeof__ support for pickle
http://bugs.python.org/issue15513
#15511: _decimal does not build in PGUpdate mode
http://bugs.python.org/issue15511
#15510: textwrap.wrap('') returns empty list
http://bugs.python.org/issue15510
#15509: webbrowser.open sometimes passes zero-length argument to the b
http://bugs.python.org/issue15509
Top 10 most discussed issues (10)
=================================
#15502: Meta path finders and path entry finders are different, but sh
http://bugs.python.org/issue15502 54 msgs
#14814: Implement PEP 3144 (the ipaddress module)
http://bugs.python.org/issue14814 25 msgs
#15510: textwrap.wrap('') returns empty list
http://bugs.python.org/issue15510 25 msgs
#15496: harden directory removal for tests on Windows
http://bugs.python.org/issue15496 17 msgs
#15544: math.isnan fails with some Decimal NaNs
http://bugs.python.org/issue15544 14 msgs
#13072: Getting a buffer from a Unicode array uses invalid format
http://bugs.python.org/issue13072 10 msgs
#15550: Trailing white spaces
http://bugs.python.org/issue15550 10 msgs
#15231: update PyPI upload doc to say --no-raw passed to rst2html.py
http://bugs.python.org/issue15231 9 msgs
#15511: _decimal does not build in PGUpdate mode
http://bugs.python.org/issue15511 9 msgs
#15494: Move test/support.py into a test.support subpackage
http://bugs.python.org/issue15494 8 msgs
Issues closed (48)
==================
#8847: crash appending list and namedtuple
http://bugs.python.org/issue8847 closed by loewis
#12073: regrtest: use faulthandler to dump the tracebacks on SIGUSR1
http://bugs.python.org/issue12073 closed by haypo
#12288: tkinter SimpleDialog initialvalue
http://bugs.python.org/issue12288 closed by asvetlov
#12507: tkSimpleDialog problem
http://bugs.python.org/issue12507 closed by ronaldoussoren
#13052: IDLE: replace ending with '\' causes crash
http://bugs.python.org/issue13052 closed by asvetlov
#13119: Newline for print() is \n on Windows, and not \r\n as expected
http://bugs.python.org/issue13119 closed by python-dev
#13371: Some Carbon extensions don't build on OSX 10.7
http://bugs.python.org/issue13371 closed by ronaldoussoren
#14018: OS X installer does not detect bad symlinks created by Xcode 3
http://bugs.python.org/issue14018 closed by ned.deily
#15077: Regexp match goes into infinite loop
http://bugs.python.org/issue15077 closed by storchaka
#15202: followlinks/follow_symlinks/symlinks flags unification
http://bugs.python.org/issue15202 closed by storchaka
#15295: Import machinery documentation
http://bugs.python.org/issue15295 closed by barry
#15441: test_posixpath fails on Japanese edition of Windows
http://bugs.python.org/issue15441 closed by haypo
#15463: test_faulthandler can fail if install path is too long
http://bugs.python.org/issue15463 closed by haypo
#15469: Correct __sizeof__ support for deque
http://bugs.python.org/issue15469 closed by python-dev
#15470: Stuck/hang when reading ssl object
http://bugs.python.org/issue15470 closed by seamus.mckenna
#15473: importlib no longer uses imp.NullImporter
http://bugs.python.org/issue15473 closed by brett.cannon
#15481: Add exec_module() as part of the import loader API
http://bugs.python.org/issue15481 closed by eric.snow
#15482: __import__() change between 3.2 and 3.3
http://bugs.python.org/issue15482 closed by brett.cannon
#15486: Standardised mechanism for stripping importlib frames from tra
http://bugs.python.org/issue15486 closed by python-dev
#15492: textwrap.wrap expand_tabs does not behave as expected
http://bugs.python.org/issue15492 closed by r.david.murray
#15499: Sleep is hardcoded in webbrowser.UnixBrowser
http://bugs.python.org/issue15499 closed by python-dev
#15503: concatenating string in dict unexpected performance
http://bugs.python.org/issue15503 closed by pitrou
#15508: __import__.__doc__ has outdated information about level
http://bugs.python.org/issue15508 closed by brett.cannon
#15512: Correct __sizeof__ support for parser
http://bugs.python.org/issue15512 closed by python-dev
#15514: Correct __sizeof__ support for cpu_set
http://bugs.python.org/issue15514 closed by python-dev
#15515: Regular expression match does not return
http://bugs.python.org/issue15515 closed by crouleau
#15517: Minor trimming for ASDL parser
http://bugs.python.org/issue15517 closed by python-dev
#15519: finish exposing WindowsRegistryImporter in importlib
http://bugs.python.org/issue15519 closed by ncoghlan
#15521: Dev Guide should say how to run tests in 2.7
http://bugs.python.org/issue15521 closed by ezio.melotti
#15524: Dict items() ordering varies across interpreter invocations
http://bugs.python.org/issue15524 closed by pitrou
#15525: test_multiprocessing failure on Windows XP
http://bugs.python.org/issue15525 closed by sbt
#15529: PyIter_Check evaluates to 0 for Python list object
http://bugs.python.org/issue15529 closed by benjamin.peterson
#15530: Enhance Py_MIN and Py_MAX
http://bugs.python.org/issue15530 closed by loewis
#15531: os.path symlink docs missing
http://bugs.python.org/issue15531 closed by larry
#15532: "for line in file" is *still* broken in Python 2.7 on pipes
http://bugs.python.org/issue15532 closed by ned.deily
#15534: xmlrpc escaping breaks on unicode \u043c
http://bugs.python.org/issue15534 closed by python-dev
#15536: re.split doesn't respect MULTILINE
http://bugs.python.org/issue15536 closed by r.david.murray
#15537: MULTILINE confuses re.split
http://bugs.python.org/issue15537 closed by ezio.melotti
#15538: Avoid nonstandard s6_addr8
http://bugs.python.org/issue15538 closed by pitrou
#15540: Python 3.3 and numpy
http://bugs.python.org/issue15540 closed by ncoghlan
#15541: logging.exception doesn't accept 'extra'
http://bugs.python.org/issue15541 closed by vinay.sajip
#15546: Iteration breaks with bz2.open(filename,'rt')
http://bugs.python.org/issue15546 closed by nadeem.vawda
#15547: Why do we have os.truncate() and os.ftruncate() whereas os.tru
http://bugs.python.org/issue15547 closed by larry
#15551: Unit tests that return generators silently fail
http://bugs.python.org/issue15551 closed by michael.foord
#15558: webbrowser output to console
http://bugs.python.org/issue15558 closed by r.david.murray
#15559: Bad interaction between ipaddress addresses and the bytes cons
http://bugs.python.org/issue15559 closed by python-dev
#15560: _sqlite3.so is built with wrong include file on OS X when usin
http://bugs.python.org/issue15560 closed by ned.deily
#15562: CaseFolding not working properly
http://bugs.python.org/issue15562 closed by benjamin.peterson
From rdmurray at bitdance.com Mon Aug 6 03:30:13 2012
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 05 Aug 2012 21:30:13 -0400
Subject: [Python-Dev] No summary of tracker issues this week?
In-Reply-To: <501F042A.6010702@mrabarnett.plus.com>
References:
<501F042A.6010702@mrabarnett.plus.com>
Message-ID: <20120806013014.58FBA2500FA@webabinitio.net>
On Mon, 06 Aug 2012 00:39:22 +0100, MRAB wrote:
> On 05/08/2012 23:31, Mark Lawrence wrote:
> > Hi all,
> >
> > I keep an eye open for this but can't find one for Saturday 03/08/2012.
> > Have I missed it, has it been stopped, has something gone wrong with
> > its production or what?
> >
> I haven't seen it either.
Thanks for noticing. It should be fixed now. I triggered a run
of the report manually, but be aware that it reports the last
week, so it starts from last Monday early AM UTC, and ends
now...so there will be some reporting overlap in next Friday's
report. (Not that that should matter much unless someone is
using them to track week-to-week statistics.)
--David
From dinov at microsoft.com Tue Aug 7 01:31:57 2012
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 6 Aug 2012 23:31:57 +0000
Subject: [Python-Dev] yield from, user defined iterators,
and StopIteration w/ a value...
Message-ID:
I'm trying to create an object which works like a generator and delegates to a generator for its implementation, but can also participate in yield from using 3.3 beta. I want my wrapper object to be able to cache some additional information - such as whether or not the generator has completed - as well as have it provide some additional methods for interacting with the state of the generator. But currently this doesn't seem possible because raising StopIteration from a user defined iterator has its value ignored as far as yield from is concerned. Here's a simplified example of the problem:
class C:
def __iter__(self): return self
def __next__(self):
raise StopIteration(100)
def g():
if False:
yield 100
return 100
def f(val):
x = yield from val
print('x', x)
print(list(f(C())))
print(list(f(g())))
Which outputs:
x None
[]
x 100
[]
So you can see for the C case the value I raise from StopIteration is ignored, but the value from the generator is propagated out. From my reading of PEP 380 the behavior here is incorrect for the user defined iterator case. next(iter(C())) raises StopIteration exception with a value and that should be the resulting value of the yield from expression according to the formal semantics.
Ok, looking at the implementation this seems to be because PyIter_Next clears the exception which prevents it from being seen in the yield from code path. So should yield from just be doing "(*iter->ob_type->tp_iternext)(iter);" directly and avoid the error checking code? Or am I wrong and this is the intended behavior?
From benjamin at python.org Tue Aug 7 02:02:35 2012
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 6 Aug 2012 17:02:35 -0700
Subject: [Python-Dev] yield from, user defined iterators,
and StopIteration w/ a value...
In-Reply-To:
References:
Message-ID:
2012/8/6 Dino Viehland :
> I'm trying to create an object which works like a generator and delegates to a generator for its implementation, but can also participate in yield from using 3.3 beta. I want my wrapper object to be able to cache some additional information - such as whether or not the generator has completed - as well as have it provide some additional methods for interacting with the state of the generator. But currently this doesn't seem possible because raising StopIteration from a user defined iterator has its value ignored as far as yield from is concerned. Here's a simplified example of the problem:
>
> class C:
> def __iter__(self): return self
> def __next__(self):
> raise StopIteration(100)
>
>
> def g():
> if False:
> yield 100
> return 100
>
> def f(val):
> x = yield from val
> print('x', x)
>
> print(list(f(C())))
> print(list(f(g())))
>
> Which outputs:
> x None
> []
> x 100
> []
>
> So you can see for the C case the value I raise from StopIteration is ignored, but the value from the generator is propagated out. From my reading of PEP 380 the behavior here is incorrect for the user defined iterator case. next(iter(C())) raises StopIteration exception with a value and that should be the resulting value of the yield from expression according to the formal semantics.
Looks like a bug to me. Please file an issue.
>
> Ok, looking at the implementation this seems to be because PyIter_Next clears the exception which prevents it from being seen in the yield from code path. So should yield from just be doing "(*iter->ob_type->tp_iternext)(iter);" directly and avoid the error checking code? Or am I wrong and this is the intended behavior?
This is probably the simpliest fix. In C, returning NULL from __next__
with no exception set is shorthand for StopIteration.
--
Regards,
Benjamin
From ncoghlan at gmail.com Tue Aug 7 03:54:00 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 7 Aug 2012 11:54:00 +1000
Subject: [Python-Dev] yield from, user defined iterators,
and StopIteration w/ a value...
In-Reply-To:
References:
Message-ID:
On Tue, Aug 7, 2012 at 10:02 AM, Benjamin Peterson wrote:
> 2012/8/6 Dino Viehland :
>> I'm trying to create an object which works like a generator and delegates to a generator for its implementation, but can also participate in yield from using 3.3 beta. I want my wrapper object to be able to cache some additional information - such as whether or not the generator has completed - as well as have it provide some additional methods for interacting with the state of the generator. But currently this doesn't seem possible because raising StopIteration from a user defined iterator has its value ignored as far as yield from is concerned. Here's a simplified example of the problem:
>>
>> class C:
>> def __iter__(self): return self
>> def __next__(self):
>> raise StopIteration(100)
>>
>>
>> def g():
>> if False:
>> yield 100
>> return 100
>>
>> def f(val):
>> x = yield from val
>> print('x', x)
>>
>> print(list(f(C())))
>> print(list(f(g())))
>>
>> Which outputs:
>> x None
>> []
>> x 100
>> []
>>
>> So you can see for the C case the value I raise from StopIteration is ignored, but the value from the generator is propagated out. From my reading of PEP 380 the behavior here is incorrect for the user defined iterator case. next(iter(C())) raises StopIteration exception with a value and that should be the resulting value of the yield from expression according to the formal semantics.
>
> Looks like a bug to me. Please file an issue.
>
>>
>> Ok, looking at the implementation this seems to be because PyIter_Next clears the exception which prevents it from being seen in the yield from code path. So should yield from just be doing "(*iter->ob_type->tp_iternext)(iter);" directly and avoid the error checking code? Or am I wrong and this is the intended behavior?
>
> This is probably the simpliest fix. In C, returning NULL from __next__
> with no exception set is shorthand for StopIteration.
+1 from me for the simple fix.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
From stefan_ml at behnel.de Tue Aug 7 22:52:30 2012
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 07 Aug 2012 22:52:30 +0200
Subject: [Python-Dev] PEP 366 is unclear about what it specifies
Message-ID:
Hi,
could someone please add a sentence to PEP 366 that describes the actual
content of the new "__package__" attribute (and thus, the PEP)?
http://www.python.org/dev/peps/pep-0366/
I had to read through almost the entire document to be assured that
"__package__" is really supposed to contain a string and I had a hard time
nailing down its content. The only real hint in there is the example, and
even that is ambiguous.
Please change the first paragraph in the "proposed change" section to this:
"""
The major proposed change is the introduction of a new module level
[NEW]string[/NEW] attribute, __package__.[NEW:] It contains the fully
qualified name of the package that the module lives in, without the module
name itself[/NEW]. When it is present, ...
"""
Thanks,
Stefan
From brett at python.org Tue Aug 7 23:26:48 2012
From: brett at python.org (Brett Cannon)
Date: Tue, 7 Aug 2012 17:26:48 -0400
Subject: [Python-Dev] PEP 366 is unclear about what it specifies
In-Reply-To:
References:
Message-ID:
On Tue, Aug 7, 2012 at 4:52 PM, Stefan Behnel wrote:
> Hi,
>
> could someone please add a sentence to PEP 366 that describes the actual
> content of the new "__package__" attribute (and thus, the PEP)?
>
> http://www.python.org/dev/peps/pep-0366/
>
> I had to read through almost the entire document to be assured that
> "__package__" is really supposed to contain a string and I had a hard time
> nailing down its content. The only real hint in there is the example, and
> even that is ambiguous.
>
Two things when it comes to understanding import now. One is that Barry's
heavy rewrite of the import docs makes all of this much clearer and thus
should be used as the reference over the PEPs, e.g.
http://docs.python.org/dev/py3k/reference/import.html?highlight=__package__#loaders
explains
how __package__ should be set very clearly (yes, it references PEP 366 for
nitty-gritty discussion and details, but honestly there isn't anything in
the PEP that he didn't explain in the reference).
Two is that importlib makes it fairly straight-forward to read the source
code to understand how some aspect of imports work and should be clear
enough to not require reading PEPs to understand how a feature works.
Honestly, updating the PEPs constantly is a pain. We have code and docs
already that most users follow, so worrying about constantly touching up
PEPs is simply a third thing to have to keep track of that a majority of
our users will never see. I know I don't plan to touch PEP 302 anymore in
order to keep things straight in that doc as it's more hassle than it's
worth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From martin at v.loewis.de Wed Aug 8 00:25:36 2012
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Wed, 08 Aug 2012 00:25:36 +0200
Subject: [Python-Dev] PEP 366 is unclear about what it specifies
In-Reply-To:
References:
Message-ID: <502195E0.9060100@v.loewis.de>
> Honestly, updating the PEPs constantly is a pain.
Please understand that Stefan's request is not about updating the PEP
in order to match the current implementation - I agree that this is a
pain, and should not be done. Consequentially, relying on the PEPs
to understand what CPython does is also flawed.
However, what Stefan requests is that the PEP be changed to say what
really is the minimum requirement for acceptance - that the PEP actually
says what the proposed change is. What it currently does say is
the "change is the introduction of a new module level attribute,
__package__". It nowhere says what value this attribute will have;
setting it to math.PI would be conforming, but clearly not intended.
The only occurrence of the word "string" is the sentence
"Note that setting __package__ to the empty string explicitly is
permitted". So we know at least one possible value of the attribute:
the empty string - but that still clearly isn't the intention of the
PEP.
Of course, it's up to the PEP author to make a change, and perhaps
(to some degree) to non-author committers (who all can take the
role of a PEP editor, acknowledging that the proposed change
is editorial).
FWIW, the documentation (simple_stmts.rst) says that __package__
(if present) is "the name of package that contains the module or
package".
Regards,
Martin
From ncoghlan at gmail.com Wed Aug 8 01:00:12 2012
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 8 Aug 2012 09:00:12 +1000
Subject: [Python-Dev] PEP 366 is unclear about what it specifies
In-Reply-To: <502195E0.9060100@v.loewis.de>
References:
<502195E0.9060100@v.loewis.de>
Message-ID:
I'm pretty sure the PEP already limits it to the same type as__name__, but
I'll check. We may have assumed that was obvious, so nobody noticed I had
left it out at the time.
--
Sent from my phone, thus the relative brevity :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From raymond.hettinger at gmail.com Wed Aug 8 09:54:48 2012
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 8 Aug 2012 00:54:48 -0700
Subject: [Python-Dev] What's New in Python 3.3
Message-ID: <4F5145DA-2810-4DEE-B662-9CB3B7247F27@gmail.com>
Hello all,
I'll soon be starting the edits of Whatsnew for 3.3.
When I did this for 3.2, it took over 150 hours of work to research all the changes. This time there are many more changes, so my previous process won't work (reviewing every "new in 3.3" entry in the docs, every entry in the voluminous Misc/NEWS file, etc).
You can help out by checking-in draft entries for your favorite new features. That way, I can avoid the time consuming curation step and focus on the text, organization, and examples.
I appreciate your help,
Raymond
From stefan at bytereef.org Wed Aug 8 12:30:53 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Wed, 8 Aug 2012 12:30:53 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
Message-ID: <20120808103053.GA29719@sleipnir.bytereef.org>
Hello,
currently the only cheap way for developers to test on SPARC that I'm
aware of is using this old Debian qemu image:
http://people.debian.org/~aurel32/qemu/sparc/
That image still uses linuxthreads and may contain any number of platform
bugs. It is currently impossible to run the test suite without bus errors,
see:
http://bugs.python.org/issue15589
Could someone with access to a SPARC machine (perhaps with a modern version
of Debian-sparc) grab a clone from http://hg.python.org/cpython/ and run
the test suite?
Also, it would be really nice if someone could donate a SPARC buildbot.
Stefan Krah
From stefan at bytereef.org Wed Aug 8 12:47:00 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Wed, 8 Aug 2012 12:47:00 +0200
Subject: [Python-Dev] Understanding the buffer API
In-Reply-To:
References: <501C5FF8.10209@farowl.co.uk>
<20120804091150.GA12337@sleipnir.bytereef.org>
<501D283F.9050207@farowl.co.uk>
<20120804152549.GA16358@sleipnir.bytereef.org>
<20120804164140.GA16845@sleipnir.bytereef.org>
Message-ID: <20120808104700.GA29854@sleipnir.bytereef.org>
Nick Coghlan wrote:
> It does place a constraint on consumers that they can't assume those
> fields will be NULL just because they didn't ask for them, but I'm
> struggling to think of any reason why a client would actually *check*
> that instead of just assuming it.
Can we continue this discussion some other time, perhaps after 3.3 is out?
I'd like to respond, but need a bit more time to think about it than I have
right now (for this issue).
Stefan Krah
From martin at v.loewis.de Wed Aug 8 15:25:12 2012
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 08 Aug 2012 15:25:12 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To: <20120808103053.GA29719@sleipnir.bytereef.org>
References: <20120808103053.GA29719@sleipnir.bytereef.org>
Message-ID: <502268B8.2090903@v.loewis.de>
> Could someone with access to a SPARC machine (perhaps with a modern version
> of Debian-sparc) grab a clone from http://hg.python.org/cpython/ and run
> the test suite?
I'd invoke the "scratch your own itch" principle here. SPARC, these
days, is a "minority platform"; I wouldn't mind deleting all SPARC
support from Python in some upcoming release. In no way I feel obliged
to take efforts that Python 3.3 works on SPARC (and remember that it
was me who donated the first buildbot slave, and that was a SPARC
machine - which I now had to take down, ten years later).
Of course, when somebody has access to SPARC hardware, *and* they
have some interest that Python 3.3 works on it, they should test it.
But testing it as a favor to the community is IMO irrelevant now;
that particular community is shrinking rapidly.
What I personally really never cared about is SparcLinux;
if sparc, then it ought to be Solaris.
IOW: if it breaks, no big deal. Someone may or may not contribute
a patch.
Regards,
Martin
From fwierzbicki at gmail.com Wed Aug 8 17:19:52 2012
From: fwierzbicki at gmail.com (fwierzbicki at gmail.com)
Date: Wed, 8 Aug 2012 08:19:52 -0700
Subject: [Python-Dev] What's New in Python 3.3
In-Reply-To: <4F5145DA-2810-4DEE-B662-9CB3B7247F27@gmail.com>
References: <4F5145DA-2810-4DEE-B662-9CB3B7247F27@gmail.com>
Message-ID:
On Wed, Aug 8, 2012 at 12:54 AM, Raymond Hettinger
wrote:
> Hello all,
>
> I'll soon be starting the edits of Whatsnew for 3.3.
>
> When I did this for 3.2, it took over 150 hours of work to research all the changes. This time there are many more changes, so my previous process won't work (reviewing every "new in 3.3" entry in the docs, every entry in the voluminous Misc/NEWS file, etc).
>
Thanks for all of this work! And thanks to A.M. Kuchling and everyone
else that goes through the effort to make the "What's new in Python"
documents so great. They are my high level roadmap for re-implementing
in Jython. It would be so much harder without them.
-Frank
From solipsis at pitrou.net Wed Aug 8 19:56:41 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 08 Aug 2012 19:56:41 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To: <502268B8.2090903@v.loewis.de>
References: <20120808103053.GA29719@sleipnir.bytereef.org>
<502268B8.2090903@v.loewis.de>
Message-ID:
Le 08/08/2012 15:25, "Martin v. L?wis" a ?crit :
>
> Of course, when somebody has access to SPARC hardware, *and* they
> have some interest that Python 3.3 works on it, they should test it.
> But testing it as a favor to the community is IMO irrelevant now;
> that particular community is shrinking rapidly.
>
> What I personally really never cared about is SparcLinux;
> if sparc, then it ought to be Solaris.
What Martin said; SPARC under Linux is probably a hobbyist platform.
Enterprise users of Solaris SPARC systems can still volunteer to provide
and maintain a buildslave.
Regards
Antoine.
From victor.stinner at gmail.com Thu Aug 9 01:04:46 2012
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 9 Aug 2012 01:04:46 +0200
Subject: [Python-Dev] What's New in Python 3.3
In-Reply-To: <4F5145DA-2810-4DEE-B662-9CB3B7247F27@gmail.com>
References: <4F5145DA-2810-4DEE-B662-9CB3B7247F27@gmail.com>
Message-ID:
Does Python 3.3 support cross-compilation? There are two new option
for configure: --host and --build, but it's not mentioned in What's
New in Python 3.3.
Victor
From flub at devork.be Thu Aug 9 01:26:26 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 9 Aug 2012 00:26:26 +0100
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To:
References: <20120808103053.GA29719@sleipnir.bytereef.org>
<502268B8.2090903@v.loewis.de>
Message-ID:
On 8 August 2012 18:56, Antoine Pitrou wrote:
> Le 08/08/2012 15:25, "Martin v. L?wis" a ?crit :
>
>>
>> Of course, when somebody has access to SPARC hardware, *and* they
>> have some interest that Python 3.3 works on it, they should test it.
>> But testing it as a favor to the community is IMO irrelevant now;
>> that particular community is shrinking rapidly.
>>
>> What I personally really never cared about is SparcLinux;
>> if sparc, then it ought to be Solaris.
>
>
> What Martin said; SPARC under Linux is probably a hobbyist platform.
> Enterprise users of Solaris SPARC systems can still volunteer to provide and
> maintain a buildslave.
Is http://wiki.python.org/moin/BuildBot the relevant documentation?
It still seems to refer to subversion, I presume that is no longer
needed and just mercurial will do? I've set up a blank solaris 10
zone on a sparc T1000 with the OpenCSW toolchain (gcc 4.6.3) on our
server and installed buildslave. According to the instructions this
is the point where I ask for a slave name and password.
Also, would it make sense to support OpenCSW more out of the box?
Currently we carry some patches for setup.py in order to pick up e.g.
sqlite from /opt/csw etc. Would there be an interest in supporting
this?
Regards,
Floris
From solipsis at pitrou.net Thu Aug 9 09:11:08 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 09 Aug 2012 09:11:08 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To:
References: <20120808103053.GA29719@sleipnir.bytereef.org>
<502268B8.2090903@v.loewis.de>
Message-ID:
Le 09/08/2012 01:26, Floris Bruynooghe a ?crit :
>>
>> What Martin said; SPARC under Linux is probably a hobbyist platform.
>> Enterprise users of Solaris SPARC systems can still volunteer to provide and
>> maintain a buildslave.
>
>
> Is http://wiki.python.org/moin/BuildBot the relevant documentation?
Yes, it is, but parts of it may be out of date. Please amend the
instructions where necessary :-)
> It still seems to refer to subversion, I presume that is no longer
> needed and just mercurial will do?
True.
> I've set up a blank solaris 10
> zone on a sparc T1000 with the OpenCSW toolchain (gcc 4.6.3) on our
> server and installed buildslave. According to the instructions this
> is the point where I ask for a slave name and password.
Ok, I'll send you one in a couple of days (away from Paris right now).
> Also, would it make sense to support OpenCSW more out of the box?
> Currently we carry some patches for setup.py in order to pick up e.g.
> sqlite from /opt/csw etc. Would there be an interest in supporting
> this?
I don't know, what is OpenCSW?
I think the answer also depends on the complexity of said patches.
Regards
Antoine.
From martin at v.loewis.de Thu Aug 9 09:22:29 2012
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 09 Aug 2012 09:22:29 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To:
References: <20120808103053.GA29719@sleipnir.bytereef.org> <502268B8.2090903@v.loewis.de>
Message-ID: <50236535.7000600@v.loewis.de>
Am 09.08.12 01:26, schrieb Floris Bruynooghe:
> According to the instructions this
> is the point where I ask for a slave name and password.
Sent in a private message.
> Also, would it make sense to support OpenCSW more out of the box?
> Currently we carry some patches for setup.py in order to pick up e.g.
> sqlite from /opt/csw etc. Would there be an interest in supporting
> this?
If all that needs to be done is to add /opt/csw into search lists
where a search list already exists, I see no problem doing so - except
that this could be considered a new feature, so it might be only
possible to do it for 3.4.
If the patches are more involved, we would have to consider them
on a case-by-case basis.
Regards,
Martin
From eliben at gmail.com Thu Aug 9 10:48:50 2012
From: eliben at gmail.com (Eli Bendersky)
Date: Thu, 9 Aug 2012 11:48:50 +0300
Subject: [Python-Dev] python 3.3 b2
In-Reply-To:
References: <7E4C776A-2456-4FDC-A86F-E1F0851DEB25@gmail.com>
Message-ID:
> As I've explained on python-committers, it's currently on hold pending
> the resolution of some importlib issues as well as a bug with the
> cross-compiling code. I won't issue a concrete date, but I expect the
> release to be made some time before next Sunday.
>
The release dates on python.org aren't up-to-date. Could you update them
with the latest estimate(s). It doesn't have to be precise, but surely
there will be no RC2 release 3 days from now.
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From flub at devork.be Thu Aug 9 16:02:09 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 9 Aug 2012 15:02:09 +0100
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To: <50236535.7000600@v.loewis.de>
References: <20120808103053.GA29719@sleipnir.bytereef.org>
<502268B8.2090903@v.loewis.de>
<50236535.7000600@v.loewis.de>
Message-ID:
On 9 August 2012 08:22, "Martin v. L?wis" wrote:
> Am 09.08.12 01:26, schrieb Floris Bruynooghe:
>
>> According to the instructions this
>> is the point where I ask for a slave name and password.
>
>
> Sent in a private message.
Thanks, it seems to be working fine. I triggered a build for 27 and
3.x. I'm assuming other builds will just be triggered automatically
when needed from now on?
>> Also, would it make sense to support OpenCSW more out of the box?
>> Currently we carry some patches for setup.py in order to pick up e.g.
>> sqlite from /opt/csw etc. Would there be an interest in supporting
>> this?
>
> If all that needs to be done is to add /opt/csw into search lists
> where a search list already exists, I see no problem doing so - except
> that this could be considered a new feature, so it might be only
> possible to do it for 3.4.
It is for 2.x, setup.py seems to have changed substantially in 3.x and
I haven't built that yet with OpenCSW but I presume I just need to
find the right place there too. I'll open an issue for it instead of
discussing it here.
Regards,
Floris
From flub at devork.be Thu Aug 9 16:11:15 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 9 Aug 2012 15:11:15 +0100
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To:
References: <20120808103053.GA29719@sleipnir.bytereef.org>
<502268B8.2090903@v.loewis.de>
Message-ID:
On 9 August 2012 08:11, Antoine Pitrou wrote:
> Le 09/08/2012 01:26, Floris Bruynooghe a ?crit :
>> Also, would it make sense to support OpenCSW more out of the box?
>> Currently we carry some patches for setup.py in order to pick up e.g.
>> sqlite from /opt/csw etc. Would there be an interest in supporting
>> this?
>
> I don't know, what is OpenCSW?
> I think the answer also depends on the complexity of said patches.
OpenCSW is a community effort (CSW == Community SoftWare) to build a
repository of GNU/Linux userland binaries for Solaris. It makes
package management as simple as on GNU/Linux, e.g.: "pkgutil --install
wget gcc4core libsqlite3_dev" which would otherwise be a very long and
laborious exercise. It is very well maintained and I consider it a
must for any Solaris box which isn't tightly locked down.
As said in my other mail the patches are rather trivial but I will
open an issue to discuss there.
Regards,
Floris
From flub at devork.be Fri Aug 10 00:24:54 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 9 Aug 2012 23:24:54 +0100
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To: <20120808103053.GA29719@sleipnir.bytereef.org>
References: <20120808103053.GA29719@sleipnir.bytereef.org>
Message-ID:
Hi,
On 8 August 2012 11:30, Stefan Krah wrote:
> Could someone with access to a SPARC machine (perhaps with a modern version
> of Debian-sparc) grab a clone from http://hg.python.org/cpython/ and run
> the test suite?
One more thing that might be interesting, the OpenCSW project provides
access to their build farm to upstream maintainers. They say
various/all versions of solaris are available and compilers etc are
already setup, but I have never tried this out. In case someone is
interested in this, see
http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/
Regards,
Floris
From eliben at gmail.com Fri Aug 10 05:11:40 2012
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 10 Aug 2012 06:11:40 +0300
Subject: [Python-Dev] [Python-checkins] peps: 3.3 schedule update.
In-Reply-To: <3WtJPK4zlDzPqQ@mail.python.org>
References: <3WtJPK4zlDzPqQ@mail.python.org>
Message-ID:
Awesome, thanks!
On Thu, Aug 9, 2012 at 9:47 PM, georg.brandl wrote:
> http://hg.python.org/peps/rev/fdf8b99178c4
> changeset: 4497:fdf8b99178c4
> user: Georg Brandl
> date: Thu Aug 09 20:48:06 2012 +0200
> summary:
> 3.3 schedule update.
>
> files:
> pep-0398.txt | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
>
> diff --git a/pep-0398.txt b/pep-0398.txt
> --- a/pep-0398.txt
> +++ b/pep-0398.txt
> @@ -42,10 +42,10 @@
>
> (No new features beyond this point.)
>
> -- 3.3.0 beta 2: July 21, 2012
> -- 3.3.0 candidate 1: August 4, 2012
> -- 3.3.0 candidate 2: August 18, 2012
> -- 3.3.0 final: September 1, 2012
> +- 3.3.0 beta 2: August 11, 2012
> +- 3.3.0 candidate 1: August 25, 2012
> +- 3.3.0 candidate 2: September 8, 2012
> +- 3.3.0 final: September 22, 2012
>
> .. don't forget to update final date above as well
>
>
> --
> Repository URL: http://hg.python.org/peps
>
> _______________________________________________
> Python-checkins mailing list
> Python-checkins at python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From martin at v.loewis.de Fri Aug 10 07:38:55 2012
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 10 Aug 2012 07:38:55 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To:
References: <20120808103053.GA29719@sleipnir.bytereef.org> <502268B8.2090903@v.loewis.de>
<50236535.7000600@v.loewis.de>
Message-ID: <50249E6F.10606@v.loewis.de>
> Thanks, it seems to be working fine. I triggered a build for 27 and
> 3.x. I'm assuming other builds will just be triggered automatically
> when needed from now on?
Indeed; you have probably seen it happening in the waterfall already.
Thanks for providing that slave.
Regards,
Martin
From g.brandl at gmx.net Fri Aug 10 07:47:41 2012
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 10 Aug 2012 07:47:41 +0200
Subject: [Python-Dev] python 3.3 b2
In-Reply-To:
References: <7E4C776A-2456-4FDC-A86F-E1F0851DEB25@gmail.com>
Message-ID:
On 09.08.2012 10:48, Eli Bendersky wrote:
>
> As I've explained on python-committers, it's currently on hold pending
> the resolution of some importlib issues as well as a bug with the
> cross-compiling code. I won't issue a concrete date, but I expect the
> release to be made some time before next Sunday.
>
>
> The release dates on python.org aren't up-to-date. Could you
> update them with the latest estimate(s). It doesn't have to be precise, but
> surely there will be no RC2 release 3 days from now.
Now they are up to date again.
Georg
From martin at v.loewis.de Fri Aug 10 07:48:04 2012
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 10 Aug 2012 07:48:04 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To:
References: <20120808103053.GA29719@sleipnir.bytereef.org> <502268B8.2090903@v.loewis.de>
<50236535.7000600@v.loewis.de>
Message-ID: <5024A094.7060705@v.loewis.de>
>> Sent in a private message.
>
> Thanks, it seems to be working fine.
Actually, there appears to be a glitch in the network setup: it appears
that connections to localhost are not possible in your zone. The tests
fail with an assertion
self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
AssertionError: 128 != 146
where 128 is ENETUNREACH. It would be good if localhost was reachable
on a build slave.
Also, if you haven't done so, please make sure that the build slave
restarts when the zone or the machine is restarted. Don't worry that
restarting will abort builds in progress - that happens from time
to time on any slave.
Regards,
Martin
From stefan at bytereef.org Fri Aug 10 14:05:29 2012
From: stefan at bytereef.org (Stefan Krah)
Date: Fri, 10 Aug 2012 14:05:29 +0200
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To:
References: <20120808103053.GA29719@sleipnir.bytereef.org>
Message-ID: <20120810120529.GA18915@sleipnir.bytereef.org>
Floris Bruynooghe wrote:
> One more thing that might be interesting, the OpenCSW project provides
> access to their build farm to upstream maintainers. They say
> various/all versions of solaris are available and compilers etc are
> already setup, but I have never tried this out. In case someone is
> interested in this, see
> http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/
Thanks for the link. Perhaps I'll try to get an account there.
Stefan Krah
From flub at devork.be Fri Aug 10 15:09:03 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Fri, 10 Aug 2012 14:09:03 +0100
Subject: [Python-Dev] SPARC testers (and buildbot!) needed
In-Reply-To: <5024A094.7060705@v.loewis.de>
References: <20120808103053.GA29719@sleipnir.bytereef.org>
<502268B8.2090903@v.loewis.de>
<50236535.7000600@v.loewis.de>
<5024A094.7060705@v.loewis.de>
Message-ID:
On 10 August 2012 06:48, "Martin v. L?wis" wrote:
> Actually, there appears to be a glitch in the network setup: it appears
> that connections to localhost are not possible in your zone. The tests
> fail with an assertion
>
> self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
> AssertionError: 128 != 146
>
> where 128 is ENETUNREACH. It would be good if localhost was reachable
> on a build slave.
The localhost network seems fine, which is shown by the test_socket
test just before. I think the issue here is that
socket.create_connection iterates over the result of
socket.getaddrinfo('localhost', port, 0, SOCK_STREAM) which returns
[(2, 2, 0, '', ('127.0.0.1', 0)), (26, 2, 0, '', ('::1', 0, 0, 0))] on
this host.
The first result is tried and returns ECONNREFUSED but then the second
address is tried and this returns ENETUNREACH because this host has
not IPv6 network configured. And create_connection() raises the last
exception it received.
If getaddrinfo() is called with the AI_ADDRCONFIG flag then it will
only return the IPv4 version of localhost.
I've created an issue to track this: http://bugs.python.org/issue15617
> Also, if you haven't done so, please make sure that the build slave
> restarts when the zone or the machine is restarted. Don't worry that
> restarting will abort builds in progress - that happens from time
> to time on any slave.
I'll check this, thanks for the reminder.
Regards,
Floris
From status at bugs.python.org Fri Aug 10 18:06:53 2012
From: status at bugs.python.org (Python tracker)
Date: Fri, 10 Aug 2012 18:06:53 +0200 (CEST)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20120810160653.511641C84D@psf.upfronthosting.co.za>
ACTIVITY SUMMARY (2012-08-03 - 2012-08-10)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open 3588 (+24)
closed 23808 (+44)
total 27396 (+68)
Open issues with patches: 1543
Issues opened (47)
==================
#13072: Getting a buffer from a Unicode array uses invalid format
http://bugs.python.org/issue13072 reopened by haypo
#15527: Double parens in functions references
http://bugs.python.org/issue15527 reopened by storchaka
#15552: gettext: if looking for .mo in default locations, also look in
http://bugs.python.org/issue15552 opened by Dominique.Leuenberger
#15553: Segfault in test_6_daemon_threads() of test_threading, on Mac
http://bugs.python.org/issue15553 opened by haypo
#15555: Default newlines of io.TextIOWrapper
http://bugs.python.org/issue15555 opened by ishimoto
#15556: os.stat fails for file pending delete on Windows
http://bugs.python.org/issue15556 opened by jkloth
#15557: Tests for webbrowser module
http://bugs.python.org/issue15557 opened by anton.barkovsky
#15561: update subprocess docs to reference io.TextIOWrapper
http://bugs.python.org/issue15561 opened by cjerdonek
#15564: cgi.FieldStorage should not call read_multi on files
http://bugs.python.org/issue15564 opened by patrick.vrijlandt
#15566: tarfile.TarInfo.frombuf documentation is out of date
http://bugs.python.org/issue15566 opened by sebastinas
#15569: Doc doc: incorrect description of some roles as format-only
http://bugs.python.org/issue15569 opened by cjerdonek
#15570: email.header.decode_header parses differently
http://bugs.python.org/issue15570 opened by ddvoinikov
#15571: Python version of TextIOWrapper ignores "write_through" arg
http://bugs.python.org/issue15571 opened by ncoghlan
#15573: Support unknown formats in memoryview comparisons
http://bugs.python.org/issue15573 opened by skrah
#15574: IDLE crashes using clipboard copy command on OS X with ActiveT
http://bugs.python.org/issue15574 opened by Leon.Maurer
#15575: Tutorial is unclear on multiple imports of a module.
http://bugs.python.org/issue15575 opened by roysmith
#15576: importlib: ExtensionFileLoader not used to load packages from
http://bugs.python.org/issue15576 opened by scoder
#15577: Real argc and argv in embedded interpreter
http://bugs.python.org/issue15577 opened by nordaux
#15578: Crash when modifying sys.modules during import
http://bugs.python.org/issue15578 opened by twouters
#15581: curses: segfault in addstr()
http://bugs.python.org/issue15581 opened by hut
#15582: Enhance inspect.getdoc to follow inheritance chains
http://bugs.python.org/issue15582 opened by ncoghlan
#15586: Provide some examples for usage of ElementTree methods/attribu
http://bugs.python.org/issue15586 opened by Sarbjit.singh
#15588: quopri: encodestring and decodestring handle bytes, not string
http://bugs.python.org/issue15588 opened by patrick.vrijlandt
#15589: Bus error on Debian sparc
http://bugs.python.org/issue15589 opened by skrah
#15590: --libs is inconsistent for python-config --libs and pkgconfig
http://bugs.python.org/issue15590 opened by doko
#15591: when building the extensions, stdout is lost when stdout is re
http://bugs.python.org/issue15591 opened by doko
#15592: subprocess.communicate() breaks on no input with universal new
http://bugs.python.org/issue15592 opened by cjerdonek
#15593: urlparse.parse_qs documentation wrong re: urlencode
http://bugs.python.org/issue15593 opened by Rob.Kinyon
#15594: test_copyfile_named_pipe() fails on Mac OS X Snow Leopard: OSE
http://bugs.python.org/issue15594 opened by haypo
#15595: subprocess.Popen(universal_newlines=True) does not work for ce
http://bugs.python.org/issue15595 opened by cjerdonek
#15596: pickle: Faster serialization of Unicode strings
http://bugs.python.org/issue15596 opened by haypo
#15599: test_circular_imports() of test_threaded_import fails on FreeB
http://bugs.python.org/issue15599 opened by haypo
#15600: expose the finder details used by the FileFinder path hook
http://bugs.python.org/issue15600 opened by eric.snow
#15604: PyObject_IsTrue failure checks
http://bugs.python.org/issue15604 opened by storchaka
#15605: Explain sphinx documentation building in devguide
http://bugs.python.org/issue15605 opened by Daniel.Ellis
#15606: re.VERBOSE doesn't ignore certain whitespace
http://bugs.python.org/issue15606 opened by stevencollins
#15607: New print's argument "flush" is not mentioned in docstring
http://bugs.python.org/issue15607 opened by storchaka
#15608: Improve socketserver doc
http://bugs.python.org/issue15608 opened by terry.reedy
#15609: Format string: add more fast-path
http://bugs.python.org/issue15609 opened by haypo
#15610: PyImport_ImportModuleEx always fails in 3.3 with "ValueError:
http://bugs.python.org/issue15610 opened by dmalcolm
#15611: devguide: add "core mentors" area to Experts Index
http://bugs.python.org/issue15611 opened by cjerdonek
#15612: Rewrite StringIO to use the _PyUnicodeWriter API
http://bugs.python.org/issue15612 opened by haypo
#15613: argparse ArgumentDefaultsHelpFormatter interacts badly with --
http://bugs.python.org/issue15613 opened by aj
#15615: More tests for JSON decoder to test Exceptions
http://bugs.python.org/issue15615 opened by kushaldas
#15616: logging.FileHandler not correctly created with PyYaml (unpickl
http://bugs.python.org/issue15616 opened by jordipf
#15617: FAIL: test_create_connection (test.test_socket.NetworkConnecti
http://bugs.python.org/issue15617 opened by flub
#15618: turtle.pencolor() chokes on unicode
http://bugs.python.org/issue15618 opened by apalala
Most recent 15 issues with no replies (15)
==========================================
#15618: turtle.pencolor() chokes on unicode
http://bugs.python.org/issue15618
#15615: More tests for JSON decoder to test Exceptions
http://bugs.python.org/issue15615
#15613: argparse ArgumentDefaultsHelpFormatter interacts badly with --
http://bugs.python.org/issue15613
#15609: Format string: add more fast-path
http://bugs.python.org/issue15609
#15606: re.VERBOSE doesn't ignore certain whitespace
http://bugs.python.org/issue15606
#15593: urlparse.parse_qs documentation wrong re: urlencode
http://bugs.python.org/issue15593
#15591: when building the extensions, stdout is lost when stdout is re
http://bugs.python.org/issue15591
#15588: quopri: encodestring and decodestring handle bytes, not string
http://bugs.python.org/issue15588
#15582: Enhance inspect.getdoc to follow inheritance chains
http://bugs.python.org/issue15582
#15581: curses: segfault in addstr()
http://bugs.python.org/issue15581
#15577: Real argc and argv in embedded interpreter
http://bugs.python.org/issue15577
#15569: Doc doc: incorrect description of some roles as format-only
http://bugs.python.org/issue15569
#15566: tarfile.TarInfo.frombuf documentation is out of date
http://bugs.python.org/issue15566
#15564: cgi.FieldStorage should not call read_multi on files
http://bugs.python.org/issue15564
#15557: Tests for webbrowser module
http://bugs.python.org/issue15557
Most recent 15 issues waiting for review (15)
=============================================
#15615: More tests for JSON decoder to test Exceptions
http://bugs.python.org/issue15615
#15612: Rewrite StringIO to use the _PyUnicodeWriter API
http://bugs.python.org/issue15612
#15610: PyImport_ImportModuleEx always fails in 3.3 with "ValueError:
http://bugs.python.org/issue15610
#15609: Format string: add more fast-path
http://bugs.python.org/issue15609
#15607: New print's argument "flush" is not mentioned in docstring
http://bugs.python.org/issue15607
#15605: Explain sphinx documentation building in devguide
http://bugs.python.org/issue15605
#15604: PyObject_IsTrue failure checks
http://bugs.python.org/issue15604
#15600: expose the finder details used by the FileFinder path hook
http://bugs.python.org/issue15600
#15596: pickle: Faster serialization of Unicode strings
http://bugs.python.org/issue15596
#15595: subprocess.Popen(universal_newlines=True) does not work for ce
http://bugs.python.org/issue15595
#15590: --libs is inconsistent for python-config --libs and pkgconfig
http://bugs.python.org/issue15590
#15589: Bus error on Debian sparc
http://bugs.python.org/issue15589
#15586: Provide some examples for usage of ElementTree methods/attribu
http://bugs.python.org/issue15586
#15573: Support unknown formats in memoryview comparisons
http://bugs.python.org/issue15573
#15571: Python version of TextIOWrapper ignores "write_through" arg
http://bugs.python.org/issue15571
Top 10 most discussed issues (10)
=================================
#15510: textwrap.wrap('') returns empty list
http://bugs.python.org/issue15510 22 msgs
#15589: Bus error on Debian sparc
http://bugs.python.org/issue15589 19 msgs
#13072: Getting a buffer from a Unicode array uses invalid format
http://bugs.python.org/issue13072 17 msgs
#14814: Implement PEP 3144 (the ipaddress module)
http://bugs.python.org/issue14814 12 msgs
#15586: Provide some examples for usage of ElementTree methods/attribu
http://bugs.python.org/issue15586 12 msgs
#15216: Support setting the encoding on a text stream after creation
http://bugs.python.org/issue15216 10 msgs
#15573: Support unknown formats in memoryview comparisons
http://bugs.python.org/issue15573 10 msgs
#15595: subprocess.Popen(universal_newlines=True) does not work for ce
http://bugs.python.org/issue15595 10 msgs
#15424: __sizeof__ of array should include size of items
http://bugs.python.org/issue15424 8 msgs
#15527: Double parens in functions references
http://bugs.python.org/issue15527 8 msgs
Issues closed (43)
==================
#5819: Add PYTHONPREFIXES environment variable
http://bugs.python.org/issue5819 closed by asvetlov
#13052: IDLE: replace ending with '\' causes crash
http://bugs.python.org/issue13052 closed by asvetlov
#13119: Newline for print() is \n on Windows, and not \r\n as expected
http://bugs.python.org/issue13119 closed by python-dev
#14182: collections.Counter equality test thrown-off by zero counts
http://bugs.python.org/issue14182 closed by rhettinger
#14966: Fully document subprocess.CalledProcessError
http://bugs.python.org/issue14966 closed by asvetlov
#15077: Regexp match goes into infinite loop
http://bugs.python.org/issue15077 closed by storchaka
#15163: pydoc displays __loader__ as module data
http://bugs.python.org/issue15163 closed by brett.cannon
#15202: followlinks/follow_symlinks/symlinks flags unification
http://bugs.python.org/issue15202 closed by storchaka
#15365: Traceback reporting can fail if IO cannot be imported
http://bugs.python.org/issue15365 closed by kristjan.jonsson
#15471: importlib's __import__() argument style nit
http://bugs.python.org/issue15471 closed by brett.cannon
#15482: __import__() change between 3.2 and 3.3
http://bugs.python.org/issue15482 closed by brett.cannon
#15492: textwrap.wrap expand_tabs does not behave as expected
http://bugs.python.org/issue15492 closed by r.david.murray
#15501: Document exception classes in subprocess module
http://bugs.python.org/issue15501 closed by asvetlov
#15530: Enhance Py_MIN and Py_MAX
http://bugs.python.org/issue15530 closed by loewis
#15531: os.path symlink docs missing
http://bugs.python.org/issue15531 closed by larry
#15536: re.split doesn't respect MULTILINE
http://bugs.python.org/issue15536 closed by r.david.murray
#15541: logging.exception doesn't accept 'extra'
http://bugs.python.org/issue15541 closed by vinay.sajip
#15546: Iteration breaks with bz2.open(filename,'rt')
http://bugs.python.org/issue15546 closed by nadeem.vawda
#15547: Why do we have os.truncate() and os.ftruncate() whereas os.tru
http://bugs.python.org/issue15547 closed by larry
#15550: Trailing white spaces
http://bugs.python.org/issue15550 closed by ned.deily
#15551: Unit tests that return generators silently fail
http://bugs.python.org/issue15551 closed by michael.foord
#15554: correct and clarify str.splitlines() documentation
http://bugs.python.org/issue15554 closed by r.david.murray
#15558: webbrowser output to console
http://bugs.python.org/issue15558 closed by r.david.murray
#15559: Bad interaction between ipaddress addresses and the bytes cons
http://bugs.python.org/issue15559 closed by python-dev
#15560: _sqlite3.so is built with wrong include file on OS X when usin
http://bugs.python.org/issue15560 closed by ned.deily
#15562: CaseFolding not working properly
http://bugs.python.org/issue15562 closed by benjamin.peterson
#15563: wrong conversion reported by
http://bugs.python.org/issue15563 closed by loewis
#15565: pdb displays runt Exception strings
http://bugs.python.org/issue15565 closed by r.david.murray
#15567: threading.py contains undefined name in self-test code
http://bugs.python.org/issue15567 closed by brian.curtin
#15568: yield from missed StopIteration raised from iterator instead o
http://bugs.python.org/issue15568 closed by python-dev
#15572: Python2 documentation of the file() built-in function
http://bugs.python.org/issue15572 closed by python-dev
#15579: some unicode keys not found using in dictionary.keys()
http://bugs.python.org/issue15579 closed by r.david.murray
#15580: fix True/False/None reST markup
http://bugs.python.org/issue15580 closed by georg.brandl
#15583: Provide examples in Python doc for usage of various modules
http://bugs.python.org/issue15583 closed by r.david.murray
#15584: os.popen deprecation warning not in Python 3 docs
http://bugs.python.org/issue15584 closed by r.david.murray
#15585: usage of os.popen in standard library
http://bugs.python.org/issue15585 closed by r.david.murray
#15587: IDLE is pixelated on the Macbook Pro with Retina Display
http://bugs.python.org/issue15587 closed by ned.deily
#15597: exception __suppress_context__ test failures on OS X ppc syste
http://bugs.python.org/issue15597 closed by python-dev
#15598: relative import unexpectedly binds name
http://bugs.python.org/issue15598 closed by benjamin.peterson
#15601: tkinter test_variables fails with OS X Aqua Tk 8.4
http://bugs.python.org/issue15601 closed by asvetlov
#15602: zipfile: wrong encoding charset of member filename
http://bugs.python.org/issue15602 closed by loewis
#15603: Multiprocessing creates incorrect pids
http://bugs.python.org/issue15603 closed by cfriedline
#15614: print statement not showing valid result
http://bugs.python.org/issue15614 closed by loewis
From apalala at gmail.com Fri Aug 10 22:52:08 2012
From: apalala at gmail.com (=?ISO-8859-1?Q?=22Juancarlo_A=F1ez_=28Apalala=29=22?=)
Date: Fri, 10 Aug 2012 16:22:08 -0430
Subject: [Python-Dev] Tests of of 2.7 tip on Ubuntu 12.04 amd64
Message-ID:
Hello,
Please let me know if this is normal:
1 test failed:
test_readline
1 test altered the execution environment:
test_subprocess
32 tests skipped:
test_aepack test_al test_applesingle test_bsddb test_bsddb185
test_bsddb3 test_cd test_cl test_curses test_dl test_gl
test_imageop test_imgfile test_kqueue test_linuxaudiodev
test_macos test_macostools test_msilib test_ossaudiodev
test_scriptpackages test_smtpnet test_socketserver test_startfile
test_sunaudiodev test_timeout test_tk test_ttk_guionly
test_urllib2net test_urllibnet test_winreg test_winsound
test_zipfile64
2 skips unexpected on linux2:
test_bsddb test_bsddb3
Thanks in advance,
--
Juancarlo
From brian at python.org Fri Aug 10 23:07:53 2012
From: brian at python.org (Brian Curtin)
Date: Fri, 10 Aug 2012 16:07:53 -0500
Subject: [Python-Dev] Tests of of 2.7 tip on Ubuntu 12.04 amd64
In-Reply-To:
References:
Message-ID:
On Fri, Aug 10, 2012 at 3:52 PM, "Juancarlo A?ez (Apalala)"
wrote:
> Hello,
>
> Please let me know if this is normal:
>
> 1 test failed:
> test_readline
> 1 test altered the execution environment:
> test_subprocess
> 32 tests skipped:
> test_aepack test_al test_applesingle test_bsddb test_bsddb185
> test_bsddb3 test_cd test_cl test_curses test_dl test_gl
> test_imageop test_imgfile test_kqueue test_linuxaudiodev
> test_macos test_macostools test_msilib test_ossaudiodev
> test_scriptpackages test_smtpnet test_socketserver test_startfile
> test_sunaudiodev test_timeout test_tk test_ttk_guionly
> test_urllib2net test_urllibnet test_winreg test_winsound
> test_zipfile64
> 2 skips unexpected on linux2:
> test_bsddb test_bsddb3
It's never normal to have tests failing. Perhaps try running
test_readline directly and then report your findings on
http://bugs.python.org
As for the skips, those are fine. As for the unexpected skips, you
probably need to install bsddb in your system for those tests to be
executed.
From solipsis at pitrou.net Fri Aug 10 23:14:38 2012
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 10 Aug 2012 23:14:38 +0200
Subject: [Python-Dev] Tests of of 2.7 tip on Ubuntu 12.04 amd64
References:
Message-ID: <20120810231438.70807a3d@pitrou.net>
On Fri, 10 Aug 2012 16:07:53 -0500
Brian Curtin wrote:
> On Fri, Aug 10, 2012 at 3:52 PM, "Juancarlo A?ez (Apalala)"
> wrote:
> > Hello,
> >
> > Please let me know if this is normal:
> >
> > 1 test failed:
> > test_readline
> > 1 test altered the execution environment:
> > test_subprocess
> > 32 tests skipped:
> > test_aepack test_al test_applesingle test_bsddb test_bsddb185
> > test_bsddb3 test_cd test_cl test_curses test_dl test_gl
> > test_imageop test_imgfile test_kqueue test_linuxaudiodev
> > test_macos test_macostools test_msilib test_ossaudiodev
> > test_scriptpackages test_smtpnet test_socketserver test_startfile
> > test_sunaudiodev test_timeout test_tk test_ttk_guionly
> > test_urllib2net test_urllibnet test_winreg test_winsound
> > test_zipfile64
> > 2 skips unexpected on linux2:
> > test_bsddb test_bsddb3
>
> It's never normal to have tests failing. Perhaps try running
> test_readline directly and then report your findings on
> http://bugs.python.org
In any case, please also take a look at
http://docs.python.org/devguide/runtests.html
Regards
Antoine.
--
Software development and contracting: http://pro.pitrou.net
From apalala at gmail.com Sat Aug 11 00:02:30 2012
From: apalala at gmail.com (=?UTF-8?Q?Juancarlo_A=C3=B1ez?=)
Date: Fri, 10 Aug 2012 17:32:30 -0430
Subject: [Python-Dev] Tests of of 2.7 tip on Ubuntu 12.04 amd64
In-Reply-To:
References:
Message-ID:
On Fri, Aug 10, 2012 at 4:37 PM, Brian Curtin wrote:
> It's never normal to have tests failing. Perhaps try running
> test_readline directly and then report your findings on
> http://bugs.python.org
>
The test script depends on a readline function not available in readline 5
or 6. Reported.
> As for the skips, those are fine. As for the unexpected skips, you
> probably need to install bsddb in your system for those tests to be
> executed.
>
The bsddb development library was missing when I issued 'make'.
As to the others:
Is the bsddb185 test still relevant in 2.7?
Why is the imageops test disabled for amd64?
Thanks!
--
Juancarlo *A?ez*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ericsnowcurrently at gmail.com Sat Aug 11 00:15:27 2012
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 10 Aug 2012 16:15:27 -0600
Subject: [Python-Dev] [Python-checkins] cpython: update docstring per
the extension package fix, refactor
In-Reply-To: <3WtyKr20cfzPHX@mail.python.org>
References: <3WtyKr20cfzPHX@mail.python.org>
Message-ID:
On Fri, Aug 10, 2012 at 2:17 PM, philip.jenvey
wrote:
> http://hg.python.org/cpython/rev/e024f6ba5ed8
> changeset: 78487:e024f6ba5ed8
> user: Philip Jenvey
> date: Fri Aug 10 11:53:54 2012 -0700
> summary:
> update docstring per the extension package fix, refactor
>
> files:
> Lib/importlib/_bootstrap.py | 9 +-
> Python/importlib.h | 3353 +++++++++++-----------
> 2 files changed, 1685 insertions(+), 1677 deletions(-)
>
>
> diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
> --- a/Lib/importlib/_bootstrap.py
> +++ b/Lib/importlib/_bootstrap.py
> @@ -1102,13 +1102,10 @@
> raise
>
> def is_package(self, fullname):
> - """Return False as an extension module can never be a package."""
> + """Return if the extension module is a package."""
s/Return if/Return True if/
-eric
From chris.jerdonek at gmail.com Sat Aug 11 01:56:43 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Fri, 10 Aug 2012 16:56:43 -0700
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Finish
bringing importlib.abc in line with the current
In-Reply-To: <3Wts5v4zWZzPvR@mail.python.org>
References: <3Wts5v4zWZzPvR@mail.python.org>
Message-ID:
On Fri, Aug 10, 2012 at 9:21 AM, brett.cannon
wrote:
> http://hg.python.org/cpython/rev/0a75ce232f56
> changeset: 78485:0a75ce232f56
> user: Brett Cannon
> date: Fri Aug 10 12:21:12 2012 -0400
> summary:
> Issue #15502: Finish bringing importlib.abc in line with the current
> + cache used by the finder. Used by :func:`invalidate_caches()` when
Minor style nit: the Dev Guide says not to include the trailing
parentheses in :func: text:
"func: The name of a Python function; dotted names may be used. The
role text should not include trailing parentheses to enhance
readability..."
(from http://hg.python.org/devguide/file/f518f23d06d5/documenting.rst#l888 )
(though I don't know why the Dev Guide says the opposite for :c:func:
and is silent on :meth:.)
On a related note: this may not be common knowledge, but it is
possible to hyperlink to a function definition while still showing
different text (in particular passed arguments) by using the following
Sphinx syntax:
:func:`locale.getpreferredencoding(False) `
This is in the Dev Guide, but I haven't seen the construct used in
many places where it seems like it would be helpful and appropriate.
--Chris
From rdmurray at bitdance.com Sat Aug 11 16:49:41 2012
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 11 Aug 2012 10:49:41 -0400
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Finish
bringing importlib.abc in line with the current
In-Reply-To:
References: <3Wts5v4zWZzPvR@mail.python.org>
Message-ID: <20120811144942.5AD662500FA@webabinitio.net>
On Fri, 10 Aug 2012 16:56:43 -0700, Chris Jerdonek wrote:
> On Fri, Aug 10, 2012 at 9:21 AM, brett.cannon
> wrote:
> > http://hg.python.org/cpython/rev/0a75ce232f56
> > changeset: 78485:0a75ce232f56
> > user: Brett Cannon
> > date: Fri Aug 10 12:21:12 2012 -0400
> > summary:
> > Issue #15502: Finish bringing importlib.abc in line with the current
>
> > + cache used by the finder. Used by :func:`invalidate_caches()` when
>
> Minor style nit: the Dev Guide says not to include the trailing
> parentheses in :func: text:
>
> "func: The name of a Python function; dotted names may be used. The
> role text should not include trailing parentheses to enhance
> readability..."
>
> (from http://hg.python.org/devguide/file/f518f23d06d5/documenting.rst#l888 )
>
> (though I don't know why the Dev Guide says the opposite for :c:func:
> and is silent on :meth:.)
To clarify: :func: automatically adds the ()s, so if you put them in
the source you get double: invalidate_caches()(). As Chris said,
use the 'alternate text' form if you want to show a call with arguments.
--David
From g.brandl at gmx.net Sat Aug 11 18:40:35 2012
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 11 Aug 2012 18:40:35 +0200
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Finish
bringing importlib.abc in line with the current
In-Reply-To: <20120811144942.5AD662500FA@webabinitio.net>
References: <3Wts5v4zWZzPvR@mail.python.org>
<20120811144942.5AD662500FA@webabinitio.net>
Message-ID:
On 08/11/2012 04:49 PM, R. David Murray wrote:
> On Fri, 10 Aug 2012 16:56:43 -0700, Chris Jerdonek wrote:
>> On Fri, Aug 10, 2012 at 9:21 AM, brett.cannon
>> wrote:
>> > http://hg.python.org/cpython/rev/0a75ce232f56
>> > changeset: 78485:0a75ce232f56
>> > user: Brett Cannon
>> > date: Fri Aug 10 12:21:12 2012 -0400
>> > summary:
>> > Issue #15502: Finish bringing importlib.abc in line with the current
>>
>> > + cache used by the finder. Used by :func:`invalidate_caches()` when
>>
>> Minor style nit: the Dev Guide says not to include the trailing
>> parentheses in :func: text:
>>
>> "func: The name of a Python function; dotted names may be used. The
>> role text should not include trailing parentheses to enhance
>> readability..."
>>
>> (from http://hg.python.org/devguide/file/f518f23d06d5/documenting.rst#l888 )
>>
>> (though I don't know why the Dev Guide says the opposite for :c:func:
>> and is silent on :meth:.)
>
> To clarify: :func: automatically adds the ()s, so if you put them in
> the source you get double: invalidate_caches()().
That is not true: they are stripped if present before they are added again.
What will give double parens is if you don't leave them empty, such as
:func:`invalidate_caches(foo)`. This is because the reference markup is not
meant for code snippets.
Georg
From chris.jerdonek at gmail.com Sat Aug 11 19:05:08 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Sat, 11 Aug 2012 10:05:08 -0700
Subject: [Python-Dev] [Python-checkins] cpython: Issue #15502: Finish
bringing importlib.abc in line with the current
In-Reply-To:
References: <3Wts5v4zWZzPvR@mail.python.org>
<20120811144942.5AD662500FA@webabinitio.net>
Message-ID:
On Sat, Aug 11, 2012 at 9:40 AM, Georg Brandl