Mailman 3 June 2013 - Python-Dev

PEP 1, PEP Purpose and Guidelines
by barry＠zope.com May 18, 2021

May 18, 2021

It has been a while since I posted a copy of PEP 1 to the mailing lists and newsgroups. I've recently done some updating of a few sections, so in the interest of gaining wider community participation in the Python development process, I'm posting the latest revision of PEP 1 here. A version of the PEP is always available on-line at http://www.python.org/peps/pep-0001.html Enjoy, -Barry -------------------- snip snip -------------------- PEP: 1 Title: PEP Purpose and Guidelines Version: $Revision: 1.36 $ Last-Modified: $Date: 2002/07/29 18:34:59 $ Author: Barry A. Warsaw, Jeremy Hylton Status: Active Type: Informational Created: 13-Jun-2000 Post-History: 21-Mar-2001, 29-Jul-2002 What is a PEP? PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python. The PEP should provide a concise technical specification of the feature and a rationale for the feature. We intend PEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions. Because the PEPs are maintained as plain text files under CVS control, their revision history is the historical record of the feature proposal[1]. Kinds of PEPs There are two kinds of PEPs. A standards track PEP describes a new feature or implementation for Python. An informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore informational PEPs or follow their advice. PEP Work Flow The PEP editor, Barry Warsaw <peps(a)python.org>, assigns numbers for each PEP and changes its status. The PEP process begins with a new idea for Python. It is highly recommended that a single PEP contain a single key proposal or new idea. The more focussed the PEP, the more successfully it tends to be. The PEP editor reserves the right to reject PEP proposals if they appear too unfocussed or too broad. If in doubt, split your PEP into several well-focussed ones. Each PEP must have a champion -- someone who writes the PEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Small enhancements or patches often don't need a PEP and can be injected into the Python development work flow with a patch submission to the SourceForge patch manager[2] or feature request tracker[3]. The PEP champion then emails the PEP editor <peps(a)python.org> with a proposed title and a rough, but fleshed out, draft of the PEP. This draft must be written in PEP style as described below. If the PEP editor approves, he will assign the PEP a number, label it as standards track or informational, give it status 'draft', and create and check-in the initial draft of the PEP. The PEP editor will not unreasonably deny a PEP. Reasons for denying PEP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Python philosophy. The BDFL (Benevolent Dictator for Life, Guido van Rossum) can be consulted during the approval phase, and is the final arbitrator of the draft's PEP-ability. If a pre-PEP is rejected, the author may elect to take the pre-PEP to the comp.lang.python newsgroup (a.k.a. python-list(a)python.org mailing list) to help flesh it out, gain feedback and consensus from the community at large, and improve the PEP for re-submission. The author of the PEP is then responsible for posting the PEP to the community forums, and marshaling community support for it. As updates are necessary, the PEP author can check in new versions if they have CVS commit permissions, or can email new PEP versions to the PEP editor for committing. Standards track PEPs consists of two parts, a design document and a reference implementation. The PEP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the PEP. Standards Track PEPs must include an implementation - in the form of code, patch, or URL to same - before it can be considered Final. PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. A PEP that has not been discussed on python-list(a)python.org and/or python-dev(a)python.org will not be accepted. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include, setting up a separate SIG mailing list for the topic, having the PEP author accept private comments in the early design phases, etc. PEP authors should use their discretion here. Once the authors have completed a PEP, they must inform the PEP editor that it is ready for review. PEPs are reviewed by the BDFL and his chosen consultants, who may accept or reject a PEP or send it back to the author(s) for revision. Once a PEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the BDFL, the status will be changed to `Final.' A PEP can also be assigned status `Deferred.' The PEP author or editor can assign the PEP this status when no progress is being made on the PEP. Once a PEP is deferred, the PEP editor can re-assign it to draft status. A PEP can also be `Rejected'. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. PEPs can also be replaced by a different PEP, rendering the original obsolete. This is intended for Informational PEPs, where version 2 of an API can replace version 1. PEP work flow is as follows: Draft -> Accepted -> Final -> Replaced ^ +----> Rejected v Deferred Some informational PEPs may also have a status of `Active' if they are never meant to be completed. E.g. PEP 1. What belongs in a successful PEP? Each PEP should have the following parts: 1. Preamble -- RFC822 style headers containing meta-data about the PEP, including the PEP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. 2. Abstract -- a short (~200 word) description of the technical issue being addressed. 3. Copyright/public domain -- Each PEP must either be explicitly labelled as placed in the public domain (see this PEP as an example) or licensed under the Open Publication License[4]. 4. Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Python platforms (CPython, JPython, Python .NET). 5. Motivation -- The motivation is critical for PEPs that want to change the Python language. It should clearly explain why the existing language specification is inadequate to address the problem that the PEP solves. PEP submissions without sufficient motivation may be rejected outright. 6. Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. 7. Backwards Compatibility -- All PEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The PEP must explain how the author proposes to deal with these incompatibilities. PEP submissions without a sufficient backwards compatibility treatise may be rejected outright. 8. Reference Implementation -- The reference implementation must be completed before any PEP is given status 'Final,' but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for either the Python language reference or the standard library reference. PEP Template PEPs are written in plain ASCII text, and should adhere to a rigid style. There is a Python script that parses this style and converts the plain text PEP to HTML for viewing on the web[5]. PEP 9 contains a boilerplate[7] template you can use to get started writing your PEP. Each PEP must begin with an RFC822 style header preamble. The headers must appear in the following order. Headers marked with `*' are optional and are described below. All other headers are required. PEP: <pep number> Title: <pep title> Version: <cvs version string> Last-Modified: <cvs date string> Author: <list of authors' real names and optionally, email addrs> * Discussions-To: <email address> Status: <Draft | Active | Accepted | Deferred | Final | Replaced> Type: <Informational | Standards Track> * Requires: <pep numbers> Created: <date created on, in dd-mmm-yyyy format> * Python-Version: <version number> Post-History: <dates of postings to python-list and python-dev> * Replaces: <pep number> * Replaced-By: <pep number> The Author: header lists the names and optionally, the email addresses of all the authors/owners of the PEP. The format of the author entry should be address(a)dom.ain (Random J. User) if the email address is included, and just Random J. User if the address is not given. If there are multiple authors, each should be on a separate line following RFC 822 continuation line conventions. Note that personal email addresses in PEPs will be obscured as a defense against spam harvesters. Standards track PEPs must have a Python-Version: header which indicates the version of Python that the feature will be released with. Informational PEPs do not need a Python-Version: header. While a PEP is in private discussions (usually during the initial Draft phase), a Discussions-To: header will indicate the mailing list or URL where the PEP is being discussed. No Discussions-To: header is necessary if the PEP is being discussed privately with the author, or on the python-list or python-dev email mailing lists. Note that email addresses in the Discussions-To: header will not be obscured. Created: records the date that the PEP was assigned a number, while Post-History: is used to record the dates of when new versions of the PEP are posted to python-list and/or python-dev. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. PEPs may have a Requires: header, indicating the PEP numbers that this PEP depends on. PEPs may also have a Replaced-By: header indicating that a PEP has been rendered obsolete by a later document; the value is the number of the PEP that replaces the current document. The newer PEP must have a Replaces: header containing the number of the PEP that it rendered obsolete. PEP Formatting Requirements PEP headings must begin in column zero and the initial letter of each word must be capitalized as in book titles. Acronyms should be in all capitals. The body of each section must be indented 4 spaces. Code samples inside body sections should be indented a further 4 spaces, and other indentation can be used as required to make the text readable. You must use two blank lines between the last line of a section's body and the next section heading. You must adhere to the Emacs convention of adding two spaces at the end of every sentence. You should fill your paragraphs to column 70, but under no circumstances should your lines extend past column 79. If your code samples spill over column 79, you should rewrite them. Tab characters must never appear in the document at all. A PEP should include the standard Emacs stanza included by example at the bottom of this PEP. A PEP must contain a Copyright section, and it is strongly recommended to put the PEP in the public domain. When referencing an external web page in the body of a PEP, you should include the title of the page in the text, with a footnote reference to the URL. Do not include the URL in the body text of the PEP. E.g. Refer to the Python Language web site [1] for more details. ... [1] http://www.python.org When referring to another PEP, include the PEP number in the body text, such as "PEP 1". The title may optionally appear. Add a footnote reference that includes the PEP's title and author. It may optionally include the explicit URL on a separate line, but only in the References section. Note that the pep2html.py script will calculate URLs automatically, e.g.: ... Refer to PEP 1 [7] for more information about PEP style ... References [7] PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton http://www.python.org/peps/pep-0001.html If you decide to provide an explicit URL for a PEP, please use this as the URL template: http://www.python.org/peps/pep-xxxx.html PEP numbers in URLs must be padded with zeros from the left, so as to be exactly 4 characters wide, however PEP numbers in text are never padded. Reporting PEP Bugs, or Submitting PEP Updates How you report a bug, or submit a PEP update depends on several factors, such as the maturity of the PEP, the preferences of the PEP author, and the nature of your comments. For the early draft stages of the PEP, it's probably best to send your comments and changes directly to the PEP author. For more mature, or finished PEPs you may want to submit corrections to the SourceForge bug manager[6] or better yet, the SourceForge patch manager[2] so that your changes don't get lost. If the PEP author is a SF developer, assign the bug/patch to him, otherwise assign it to the PEP editor. When in doubt about where to send your changes, please check first with the PEP author and/or PEP editor. PEP authors who are also SF committers, can update the PEPs themselves by using "cvs commit" to commit their changes. Remember to also push the formatted PEP text out to the web by doing the following: % python pep2html.py -i NUM where NUM is the number of the PEP you want to push out. See % python pep2html.py --help for details. Transferring PEP Ownership It occasionally becomes necessary to transfer ownership of PEPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred PEP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the PEP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the PEP. We try to build consensus around a PEP, but if that's not possible, you can always submit a competing PEP. If you are interested assuming ownership of a PEP, send a message asking to take over, addressed to both the original author and the PEP editor <peps(a)python.org>. If the original author doesn't respond to email in a timely manner, the PEP editor will make a unilateral decision (it's not like such decisions can be reversed. :). References and Footnotes [1] This historical record is available by the normal CVS commands for retrieving older revisions. For those without direct access to the CVS tree, you can browse the current and past PEP revisions via the SourceForge web site at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/?cvsroot=… [2] http://sourceforge.net/tracker/?group_id=5470&atid=305470 [3] http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse [4] http://www.opencontent.org/openpub/ [5] The script referred to here is pep2html.py, which lives in the same directory in the CVS tree as the PEPs themselves. Try "pep2html.py --help" for details. The URL for viewing PEPs on the web is http://www.python.org/peps/ [6] http://sourceforge.net/tracker/?group_id=5470&atid=305470 [7] PEP 9, Sample PEP Template http://www.python.org/peps/pep-0009.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:

8 14

More compact dictionaries with faster iteration
by Raymond Hettinger Jan. 3, 2015

Jan. 3, 2015

The current memory layout for dictionaries is unnecessarily inefficient. It has a sparse table of 24-byte entries containing the hash value, key pointer, and value pointer. Instead, the 24-byte entries should be stored in a dense table referenced by a sparse table of indices. For example, the dictionary: d = {'timmy': 'red', 'barry': 'green', 'guido': 'blue'} is currently stored as: entries = [['--', '--', '--'], [-8522787127447073495, 'barry', 'green'], ['--', '--', '--'], ['--', '--', '--'], ['--', '--', '--'], [-9092791511155847987, 'timmy', 'red'], ['--', '--', '--'], [-6480567542315338377, 'guido', 'blue']] Instead, the data should be organized as follows: indices = [None, 1, None, None, None, 0, None, 2] entries = [[-9092791511155847987, 'timmy', 'red'], [-8522787127447073495, 'barry', 'green'], [-6480567542315338377, 'guido', 'blue']] Only the data layout needs to change. The hash table algorithms would stay the same. All of the current optimizations would be kept, including key-sharing dicts and custom lookup functions for string-only dicts. There is no change to the hash functions, the table search order, or collision statistics. The memory savings are significant (from 30% to 95% compression depending on the how full the table is). Small dicts (size 0, 1, or 2) get the most benefit. For a sparse table of size t with n entries, the sizes are: curr_size = 24 * t new_size = 24 * n + sizeof(index) * t In the above timmy/barry/guido example, the current size is 192 bytes (eight 24-byte entries) and the new size is 80 bytes (three 24-byte entries plus eight 1-byte indices). That gives 58% compression. Note, the sizeof(index) can be as small as a single byte for small dicts, two bytes for bigger dicts and up to sizeof(Py_ssize_t) for huge dict. In addition to space savings, the new memory layout makes iteration faster. Currently, keys(), values, and items() loop over the sparse table, skipping-over free slots in the hash table. Now, keys/values/items can loop directly over the dense table, using fewer memory accesses. Another benefit is that resizing is faster and touches fewer pieces of memory. Currently, every hash/key/value entry is moved or copied during a resize. In the new layout, only the indices are updated. For the most part, the hash/key/value entries never move (except for an occasional swap to fill a hole left by a deletion). With the reduced memory footprint, we can also expect better cache utilization. For those wanting to experiment with the design, there is a pure Python proof-of-concept here: http://code.activestate.com/recipes/578375 YMMV: Keep in mind that the above size statics assume a build with 64-bit Py_ssize_t and 64-bit pointers. The space savings percentages are a bit different on other builds. Also, note that in many applications, the size of the data dominates the size of the container (i.e. the weight of a bucket of water is mostly the water, not the bucket). Raymond

27 70

Reviving restricted mode?
by Guido van Rossum Aug. 14, 2014

Aug. 14, 2014

I've received some enthusiastic emails from someone who wants to revive restricted mode. He started out with a bunch of patches to the CPython runtime using ctypes, which he attached to an App Engine bug: http://code.google.com/p/googleappengine/issues/detail?id=671 Based on his code (the file secure.py is all you need, included in secure.tar.gz) it seems he believes the only security leaks are __subclasses__, gi_frame and gi_code. (I have since convinced him that if we add "restricted" guards to these attributes, he doesn't need the functions added to sys.) I don't recall the exploits that Samuele once posted that caused the death of rexec.py -- does anyone recall, or have a pointer to the threads? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

19 35

CLA link from bugs.python.org
by Tim Delaney Feb. 16, 2014

Feb. 16, 2014

It appears there's no obvious link from bugs.python.org to the contributor agreement - you need to go via the unintuitive link Foundation -> Contribution Forms (and from what I've read, you're prompted when you add a patch to the tracker). I'd suggest that if the "Contributor Form Received" field is "No" in user details, there be a link to http://www.python.org/psf/contrib/. Tim Delaney

3 4

cffi in stdlib
by Maciej Fijalkowski Dec. 19, 2013

Dec. 19, 2013

Hello. I would like to discuss on the language summit a potential inclusion of cffi[1] into stdlib. This is a project Armin Rigo has been working for a while, with some input from other developers. It seems that the main reason why people would prefer ctypes over cffi these days is "because it's included in stdlib", which is not generally the reason I would like to hear. Our calls to not use C extensions and to use an FFI instead has seen very limited success with ctypes and quite a lot more since cffi got released. The API is fairly stable right now with minor changes going in and it'll definitely stablize until Python 3.4 release. Notable projects using it: * pypycore - gevent main loop ported to cffi * pgsql2cffi * sdl-cffi bindings * tls-cffi bindings * lxml-cffi port * pyzmq * cairo-cffi * a bunch of others So relatively a lot given that the project is not even a year old (it got 0.1 release in June). As per documentation, the advantages over ctypes: * The goal is to call C code from Python. You should be able to do so without learning a 3rd language: every alternative requires you to learn their own language (Cython, SWIG) or API (ctypes). So we tried to assume that you know Python and C and minimize the extra bits of API that you need to learn. * Keep all the Python-related logic in Python so that you don’t need to write much C code (unlike CPython native C extensions). * Work either at the level of the ABI (Application Binary Interface) or the API (Application Programming Interface). Usually, C libraries have a specified C API but often not an ABI (e.g. they may document a “struct” as having at least these fields, but maybe more). (ctypes works at the ABI level, whereas Cython and native C extensions work at the API level.) * We try to be complete. For now some C99 constructs are not supported, but all C89 should be, including macros (and including macro “abuses”, which you can manually wrap in saner-looking C functions). * We attempt to support both PyPy and CPython, with a reasonable path for other Python implementations like IronPython and Jython. * Note that this project is not about embedding executable C code in Python, unlike Weave. This is about calling existing C libraries from Python. so among other things, making a cffi extension gives you the same level of security as writing C (and unlike ctypes) and brings quite a bit more flexibility (API vs ABI issue) that let's you wrap arbitrary libraries, even those full of macros. Cheers, fijal .. [1]: http://cffi.readthedocs.org/en/release-0.5/

22 75

compile python 3.3 with bz2 support
by Isml Oct. 22, 2013

Oct. 22, 2013

hi, everyone: I want to compile python 3.3 with bz2 support on RedHat 5.5 but fail to do that. Here is how I do it: 1、download bzip2 and compile it(make、make -f Makefile_libbz2_so、make install) 2、chang to python 3.3 source directory : ./configure --with-bz2=/usr/local/include 3、make 4、make install after installation complete, I test it： [root@localhost Python-3.3.0]# python3 -c "import bz2" Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/python3.3/bz2.py", line 21, in <module> from _bz2 import BZ2Compressor, BZ2Decompressor ImportError: No module named '_bz2' By the way, RedHat 5.5 has a built-in python 2.4.3. Would it be a problem?

3 2

Relative path in co_filename for zipped modules
by Vitaly Murashev Sept. 15, 2013

Sept. 15, 2013

Dear Python developers community, Recently I found out that it not possible to debug python code if it is a part of zip-module. Python version being used is 3.3.0 Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to start debugging and give the following warning: --- pydev debugger: CRITICAL WARNING: This version of python seems to be incorrectly compiled (internal generated filenames are not absolute) pydev debugger: The debugger may still function, but it will work slower and may miss breakpoints. --- So I started my own investigation of this issue and results are the following. At first I took traditional python debugger 'pdb' to analyze how it behaves during debugging of zipped module. 'pdb' showed me some backtaces and filename part for stack entries looks malformed. I expected something like 'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py' but realy it looks like 'full-path-to-current-dir/subdir/test_module.py' Source code in pdb.py and bdb.py (which one are a part of python stdlib) gave me the answer why it happens. The root cause are inside Bdb.format_stack_entry() + Bdb.canonic() Please take a look at the following line inside 'format_stack_entry' method: filename = self.canonic(frame.f_code.co_filename) For zipped module variable 'frame.f_code.co_filename' holds _relative_ file path started from the root of zip archive like 'subdir/test_module.py' And as result Bdb.canonic() method gives what we have - 'full-path-to-current-dir/subdir/test_module.py' --- So my final question. Could anyone confirm that it is a bug in python core subsystem which one is responsible for loading zipped modules, or something is wrong with my zipped module ? If it is a bug could you please submit it into official python bugtracker ? I never did it before and afraid to do something wrong. Thanks, Vitaly Murashev

2 3

Make extension module initialisation more like Python module initialisation
by Stefan Behnel Aug. 6, 2013

Aug. 6, 2013

Hi, I suspect that this will be put into a proper PEP at some point, but I'd like to bring this up for discussion first. This came out of issues 13429 and 16392. http://bugs.python.org/issue13429 http://bugs.python.org/issue16392 Stefan The problem =========== Python modules and extension modules are not being set up in the same way. For Python modules, the module is created and set up first, then the module code is being executed. For extensions, i.e. shared libraries, the module init function is executed straight away and does both the creation and initialisation. This means that it knows neither the __file__ it is being loaded from nor its package (i.e. its FQMN). This hinders relative imports and resource loading. In Py3, it's also not being added to sys.modules, which means that a (potentially transitive) re-import of the module will really try to reimport it and thus run into an infinite loop when it executes the module init function again. And without the FQMN, it's not trivial to correctly add the module to sys.modules either. We specifically run into this for Cython generated modules, for which it's not uncommon that the module init code has the same level of complexity as that of any 'regular' Python module. Also, the lack of a FQMN and correct file path hinders the compilation of __init__.py modules, i.e. packages, especially when relative imports are being used at module init time. The proposal ============ I propose to split the extension module initialisation into two steps in Python 3.4, in a backwards compatible way. Step 1: The current module init function can be reduced to just creating the module instance and returning it (and potentially doing some simple C level setup). Optionally, after creating the module (and this is the new part), the module init code can register a C callback function that will be called after setting up the module. Step 2: The shared library importer receives the module instance from the module init function, adds __file__, __path__, __package__ and friends to the module dict, and then checks for the callback. If non-NULL, it calls it to continue the module initialisation by user code. The callback ============ The callback is defined as follows:: int (*PyModule_init_callback)(PyObject* the_module, PyModuleInitContext* context) "PyModuleInitContext" is a struct that is meant mostly for making the callback more future proof by allowing additional parameters to be passed in. For now, I can see a use case for the following fields:: struct PyModuleInitContext { char* module_name; char* qualified_module_name; } Both names are encoded in UTF-8. As for the file path, I consider it best to retrieve it from the module's __file__ attribute as a Python string object to reduce filename encoding problems. Note that this struct argument is not strictly required, but given that this proposal would have been much simpler if the module init function had accepted such an argument in the first place, I consider it a good idea not to let this chance pass by again. The registration of the callback uses a new C-API function: int PyModule_SetInitFunction(PyObject* module, PyModule_init_callback callback) The function name uses "Set" instead of "Register" to make it clear that there is only one such function per module. An alternative would be a new module creation function "PyModule_Create3()" that takes the callback as third argument, in addition to what "PyModule_Create2()" accepts. This would require users to explicitly pass in the (second) version argument, which might be considered only a minor issue. Implementation ============== The implementation requires local changes to the extension module importer and a new C-API function. In order to store the callback, it should use a new field in the module object struct. Open questions ============== It is not clear how extensions should be handled that register more than one module in their module init function, e.g. compiled packages. One possibility would be to leave the setup to the user, who would have to know all FQMNs anyway in this case, although not the import file path. Alternatively, the import machinery could use a stack to remember for which modules a callback was registered during the last init function call, set up all of them and then call their callbacks. It's not clear if this meets the intention of the user. Alternatives ============ 1) It would be possible to make extension modules optionally export another symbol, e.g. "PyInit2_modulename", that the shared library loader would call in addition to the required function "PyInit_modulename". This would remove the need for a new API that registers the above callback. The drawback is that it also makes it easier to write broken code because a Python version or implementation that does not support this second symbol would simply not call it, without error. The new C-API function would let the build fail instead if it is not supported. 2) The callback could be made available as a Python function in the module dict, thus also removing the need for an explicit registration API. However, this approach would add overhead to both sides, the importer code and the user provided module init code, as it would require additional dictionary handling and the implementation of a one-time Python function in user code. It would also suffer from the problem that missing support in the runtime would pass silently. 3) The callback could be registered statically in the PyModuleDef struct by adding a new field. This is not trivial to do in a backwards compatible way because the struct would grow longer without explicit initialisation by existing user code. Extending PyModuleDef_HEAD_INIT might be possible but would still break at least binary compatibility. 4) Pass a new context argument into the module init function that contains all information necessary to properly and completely set up the module at creation time. This would provide a much simpler and cleaner solution than the proposed solution. However, it will not be possible before Python 4 as it breaks backwards compatibility with all existing extension modules at both the source and binary level.

5 15

PLY in stdlib (was cffi in stdlib)
by David Beazley July 15, 2013

July 15, 2013

> > From: Eli Bendersky <eliben(a)gmail.com> > > I'll be the first one to admit that pycparser is almost certainly not > generally useful enough to be exposed in the stdlib. So just using it as an > implementation detail is absolutely fine. PLY is a more interesting > question, however, since PLY is somewhat more generally useful. That said, > I see all this as implementation details that shouldn't distract us from > the main point of whether cffi should be added. > Regarding the inclusion of PLY or some subcomponent of it in the standard library, it's not an entirely crazy idea in my opinion. LALR(1) parsers have been around for a long time, are generally known to anyone who's used yacc/bison, and would be useful outside the context of cffi or pycparser. PLY has also been around for about 12 years and is what I would call stable. It gets an update about every year or two, but that's about it. PLY is also relatively small--just two files and about 4300 lines of code (much of which could probably be scaled down a bit). The only downside to including PLY might be the fact that there are very few people walking around who've actually had to *implement* an LALR(1) parser generator. Some of the code for that is extremely hairy and mathematical. At this time, I don't think there are any bugs in it, but it's not the sort of thing that one wants to wander into casually. Also, there are some horrible hacks in PLY that I'd really like to get rid of, but am currently stuck with due to backwards compatibility issues. Alex Gaynor has been working on a PLY variant (RPLY) geared at RPython and which has a slightly different programming interface. I'd say if we were to go down this route, he and I should work together to put together some kind of more general "parsing.lalr" package (or similar) that cleans it up and makes it more suitable as a library for building different kinds of parsing tools on top of. Cheers, Dave

9 13

Rough idea for adding introspection information for builtins
by Larry Hastings July 8, 2013

July 8, 2013

The original impetus for Argument Clinic was adding introspection information for builtins--it seemed like any manual approach I came up with would push the builtins maintenance burden beyond the pale. Assuming that we have Argument Clinic or something like it, we don't need to optimize for ease of use from the API end--we can optimize for data size. So the approach writ large: store a blob of data associated with each entry point, as small as possible. Reconstitute the appropriate inspect.Signature on demand by reading that blob. Where to store the data? PyMethodDef is the obvious spot, but I think that structure is part of the stable ABI. So we'd need a new PyMethodDefEx and that'd be a little tiresome. Less violent to the ABI would be defining a new array of pointers-to-introspection-blobs, parallel to the PyMethodDef array, passed in via a new entry point. On to the representation. Consider the function def foo(arg, b=3, *, kwonly='a'): pass I considered four approaches, each listed below along with its total size if it was stored as C static data. 1. A specialized bytecode format, something like pickle, like this: bytes([ PARAMETER_START_LENGTH_3, 'a', 'r', 'g', PARAMETER_START_LENGTH_1, 'b', PARAMETER_DEFAULT_LENGTH_1, '3', KEYWORD_ONLY, PARAMETER_START_LENGTH_6, 'k', 'w', 'o', 'n', 'l', 'y', PARAMETER_DEFAULT_LENGTH_3, '\'', 'a', '\'', END ]) Length: 20 bytes. 2. Just use pickle--pickle the result of inspect.signature() run on a mocked-up signature, just store that. Length: 130 bytes. (Assume a two-byte size stored next to it.) 3. Store a string that, if eval'd, would produce the inspect.Signature. Length: 231 bytes. (This could be made smaller if we could assume "from inspect import *" or "p = inspect.Parameter" or something, but it'd still be easily the heaviest.) 4. Store a string that looks like the Python declaration of the signature, and parse it (Nick's suggestion). For foo above, this would be "(arg,b=3,*,kwonly='a')". Length: 23 bytes. Of those, Nick's suggestion seems best. It's slightly bigger than the specialized bytecode format, but it's human-readable (and human-writable!), and it'd be the easiest to implement. My first idea for implementation: add a "def x" to the front and ": pass" to the end, then run it through ast.parse. Iterate over the tree, converting parameters into inspect.Parameters and handling the return annotation if present. Default values and annotations would be turned into values by ast.eval_literal. (It wouldn't surprise me if there's a cleaner way to do it than the fake function definition; I'm not familiar with the ast module.) We'd want one more mild hack: the DSL will support positional parameters, and inspect.Signature supports positional parameters, so it'd be nice to render that information. But we can't represent that in Python syntax (or at least not yet!), so we can't let ast.parse see it. My suggestion: run it through ast.parse, and if it throws a SyntaxError see if the problem was a slash. If it was, remove the slash, reprocess through ast.parse, and remember that all parameters are positional-only (and barf if there are kwonly, args, or kwargs). Thoughts? //arry/

9 23

PEP 423 : naming conventions and recipes related to packaging
by Benoît Bryon July 5, 2013

July 5, 2013

Hi, Here is an informational PEP proposal: http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt Could you review it for style, consistency and content? Additional notes: * Original discussion posted to distutils-sig(a)python.org * started on May 2012 at http://mail.python.org/pipermail/distutils-sig/2012-May/018551.html * continues in June 2012 at http://mail.python.org/pipermail/distutils-sig/2012-June/018641.html * that's why I set "Discussion-To:<distutils-sig(a)python.org>" header. * Original document was edited as a contrib to cpython documentation: * http://bugs.python.org/issue14899 * file history at https://bitbucket.org/benoitbryon/cpython/history/Doc/packaging/packagename… * but it looked like a PEP, so posted to peps(a)python.org... Regards, Benoit (benoitbb on irc.freenode.net)

11 20

End of the mystery "@README.txt Mercurial bug"
by Victor Stinner July 1, 2013

July 1, 2013

Hi, One month ago, unit tests were added to IDLE (cool!) with a file called @README.txt. The @ was used to see the name on top in a listing of the directory. Some developers began to get strange Mercurial errors like: "abort: data/Lib/idlelib/idle_test/(a)README.txt.i at 7573717b9e6f: no match" " 83941: empty or missing Lib/idlelib/idle_test/(a)README.txt " etc. Senthil reported the issue on python-committers mailing list: http://mail.python.org/pipermail/python-committers/2013-May/002565.html The @ character was discussed. Replacing it with "_" was proposed. Guido asked to simply rename the name "README.txt", he wrote: "I think we have a zen rule about this: Special cases aren't special enough to break the rules." Senthil was asked to upgrade its Mercurial version. Someone supposed that it is a disk issue. Anyway, the issue disappeared with a fresh clone. I also had the issue on 3 different computers, and so I reported the issue upstream: http://bz.selenic.com/show_bug.cgi?id=3954 I discussed with a Mercurial developer, Matt, on IRC. He asked how the server is managed, if we are using only one physical server, if repositories are copied with rsync, etc. I was unable to answer, I don't have access to hg.python.org server. The issue was closed, but 20 days later (today) I reproduced the issue again. I cloned the repository at a specific revision, tried to update to another specific revision: no bug. I also played with with hg bisect, because I suspected a bug in bisect: no bug. I tried to update at each revision between 83900 and 84348 to check if @README.txt disappears from .hg/store: still no bug. I also ran fsck: no error (but the disk is mounted, so I don't know if the report is reliable). And then I ran "make distclean"... Victor

16 31

Issue 4199: combining assignment with global & nonlocal
by A.M. Kuchling June 29, 2013

June 29, 2013

Issue 4199 begins with a self-explanatory comment: PEP 3104 says that the nonlocal and global statements should allow a shorthand. ("global x; x = 3" == "global x = 3") This patch implements that. Benjamin posted his patch on 2008-10-24. It got postponed to 3.2 because it was too late for 3.1, and then to 3.3 because 3.2 still fell under the language moratorium, and then was forgotten for 3.3. Georg Brandl and Jeremy Hylton raised some issues with the patch and with the PEP's specification: http://bugs.python.org/issue4199#msg100015 We've gone five years in 3.x without supporting this statement form. Is it still worth implementing it for 3.4? Or should the issue simply be closed (and maybe a note added to the PEP that "we didn't do this after all")? --amk

3 2

PyArg_ParseTupe(): parse unsigned integer and check for overflow
by Victor Stinner June 29, 2013

June 29, 2013

Hi, I don't understand why the B, H, I, k formats of PyArg_ParseTupe() do not check for overflow, whereas formats for signed numbers do check for overflow. What is the useful of ignoring overflow? http://docs.python.org/3/c-api/arg.html I would to parse an integer in [0; UINT_MAX] to fix the zlib module on 64-bit system: http://bugs.python.org/issue18294 How should I implement that? Use "O" format and then use PyLong_Check(), PyLong_AsLong(), and check value <= UINT_MAX? Victor

5 4

winsound.c fix to support python3
by Tamir Friedman June 29, 2013

June 29, 2013

Hello, My name is Tamir Friedman, and I suggest to fix a bug in PlaySound in winsound library. It's doesn't support the SND_MEMORY feature because its accepts only "str" and rejects "bytes" type. therefore i include the fixed source file: OLD: ---------------------------------------------------------------------------- static PyObject * sound_playsound(PyObject *s, PyObject *args) { wchar_t *wsound; int flags; int ok; if (PyArg_ParseTuple(args, "Zi:PlaySound", &wsound, &flags)) { if (flags & SND_ASYNC && flags & SND_MEMORY) { /* Sidestep reference counting headache; unfortunately this also prevent SND_LOOP from memory. */ PyErr_SetString(PyExc_RuntimeError, "Cannot play asynchronously from memory"); return NULL; } Py_BEGIN_ALLOW_THREADS ok = PlaySoundW(wsound, NULL, flags); Py_END_ALLOW_THREADS if (!ok) { PyErr_SetString(PyExc_RuntimeError, "Failed to play sound"); return NULL; } Py_INCREF(Py_None); return Py_None; } return NULL; } ---------------------------------------------------------------------------- NEW: ---------------------------------------------------------------------------- static PyObject * sound_playsound(PyObject *s, PyObject *args) { wchar_t *wsound; int flags; int ok; if (PyArg_ParseTuple(args, "z*i:PlaySound", &wsound, &flags)) { if (flags & SND_ASYNC && flags & SND_MEMORY) { /* Sidestep reference counting headache; unfortunately this also prevent SND_LOOP from memory. */ PyErr_SetString(PyExc_RuntimeError, "Cannot play asynchronously from memory"); return NULL; } Py_BEGIN_ALLOW_THREADS ok = PlaySoundW(wsound, NULL, flags); Py_END_ALLOW_THREADS if (!ok) { PyErr_SetString(PyExc_RuntimeError, "Failed to play sound"); return NULL; } Py_INCREF(Py_None); return Py_None; } return NULL; } ----------------------------------------------------------------------------

2 1

Re: [Python-Dev] [Python-checkins] cpython: Fix memory leak in pyexpat PyUnknownEncodingHandler
by R. David Murray June 29, 2013

June 29, 2013

I don't know if this is the commit at fault or not, but we are seeing segfaults in test_xml_etree on the buildbots now. --David On Sat, 29 Jun 2013 20:43:22 +0200, christian.heimes <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/bd0834b59828 > changeset: 84375:bd0834b59828 > user: Christian Heimes <christian(a)cheimes.de> > date: Sat Jun 29 20:43:13 2013 +0200 > summary: > Fix memory leak in pyexpat PyUnknownEncodingHandler > CID 1040367 (#1 of 1): Resource leak (RESOURCE_LEAK) > leaked_storage: Variable u going out of scope leaks the storage it points to. > > files: > Modules/pyexpat.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > > diff --git a/Modules/pyexpat.c b/Modules/pyexpat.c > --- a/Modules/pyexpat.c > +++ b/Modules/pyexpat.c > @@ -1128,8 +1128,10 @@ > } > > u = PyUnicode_Decode((char*) template_buffer, 256, name, "replace"); > - if (u == NULL || PyUnicode_READY(u)) > + if (u == NULL || PyUnicode_READY(u)) { > + Py_DECREF(u); > return XML_STATUS_ERROR; > + } > > if (PyUnicode_GET_LENGTH(u) != 256) { > Py_DECREF(u); > > -- > Repository URL: http://hg.python.org/cpython > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins

2 1

backported Enum
by Ethan Furman June 29, 2013

June 29, 2013

So I have the stdlb 3.4 Enum backported for both earlier 3.x and back to 2.4 in the 2.x series. I would like to put this on PyPI, but the `enum` name is already taken. Would it be inappropriate to call it `stdlib.enum`? -- ~Ethan~

12 25

add new lambda syntax
by Pynix Wang June 29, 2013

June 29, 2013

I want use coffeescript function syntax to write python lambda expression so I modified the Grammar file. ``` atom: ('(' [yield_expr|testlist_comp|vararglist] ')' | '[' [testlist_comp] ']' | '{' [dictorsetmaker] '}' | NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False') trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME | '->' text ``` but when I write ``` (x,y=1)->x+y ``` the parser doesn't go into vararglist. any help?

3 3

Reminder: an oft-forgotten rule about docstring formatting (PEP 257)
by Guido van Rossum June 28, 2013

June 28, 2013

PEP 257 says this on the formatting of multi-line docstrings: """ Multi-line docstrings consist of a summary line just like a one-line docstring, followed by a blank line, followed by a more elaborate description. The summary line may be used by automatic indexing tools; it is important that it fits on one line and is separated from the rest of the docstring by a blank line. [...] """ I still like this rule, but it is violated frequently, in the stdlib and elsewhere. I'd like to urge stdlib contributors and core devs to heed it -- or explain why you can't. -- --Guido van Rossum (python.org/~guido)

9 14

Summary of Python tracker Issues
by Python tracker June 28, 2013

June 28, 2013

ACTIVITY SUMMARY (2013-06-21 - 2013-06-28) 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 4069 (+12) closed 26027 (+34) total 30096 (+46) Open issues with patches: 1804 Issues opened (40) ================== #7732: imp.find_module crashes Python if there exists a directory nam http://bugs.python.org/issue7732 reopened by haypo #18135: _ssl module: possible integer overflow for very long strings ( http://bugs.python.org/issue18135 reopened by pitrou #18267: xmlrpc.client documentation multicall example missleading for http://bugs.python.org/issue18267 reopened by ber #18279: IDLE Unit test for RstripExtension.py http://bugs.python.org/issue18279 opened by philwebster #18280: Documentation is too personalized http://bugs.python.org/issue18280 opened by serhiy.storchaka #18281: tarfile defines stat constants http://bugs.python.org/issue18281 opened by christian.heimes #18283: shutil.which() should support bytes http://bugs.python.org/issue18283 opened by Arfrever #18286: Python 3.3 - Slowing down computer http://bugs.python.org/issue18286 opened by jon_irenicus #18287: PyType_Ready() should sanity-check the tp_name field http://bugs.python.org/issue18287 opened by nkoep #18288: Idle 2.7: Run Module does not set __file__ http://bugs.python.org/issue18288 opened by terry.reedy #18289: python.org Interactive interpreter linked with libedit can seg http://bugs.python.org/issue18289 opened by Max.Kaye #18290: json encoder does not support JSONP/JavaScript safe escaping http://bugs.python.org/issue18290 opened by Ztane #18291: codecs.open interprets space as line ends http://bugs.python.org/issue18291 opened by wpk #18292: IDLE Improvements: Unit test for AutoExpand.py http://bugs.python.org/issue18292 opened by JayKrish #18293: ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated http://bugs.python.org/issue18293 opened by mpb #18294: zlib module is not completly 64-bit safe http://bugs.python.org/issue18294 opened by haypo #18295: Possible integer overflow in PyCode_New() http://bugs.python.org/issue18295 opened by haypo #18296: test_os.test_trailers() is failing on AMD64 FreeBSD 9.0 dtrace http://bugs.python.org/issue18296 opened by haypo #18299: Change script_helper to use universal_newlines=True in _assert http://bugs.python.org/issue18299 opened by r.david.murray #18300: script_helper._asert_python should set TERM='' by default. http://bugs.python.org/issue18300 opened by r.david.murray #18301: In itertools.chain.from_iterable() there is no cls argument http://bugs.python.org/issue18301 opened by py.user #18302: test_multiprocessing: test.support.import_module() does not ig http://bugs.python.org/issue18302 opened by haypo #18304: ElementTree gets awkward to use if there is an xmlns http://bugs.python.org/issue18304 opened by brycenesbitt #18305: [patch] Fast sum() for non-numbers http://bugs.python.org/issue18305 opened by Sergey #18306: os.stat gives exception for Windows junctions in v3.3 http://bugs.python.org/issue18306 opened by John.Jefferies #18307: Relative path in co_filename for zipped modules http://bugs.python.org/issue18307 opened by vmurashev #18308: checkRecvmsgAddress wrong in test_socket.py (AIX failures) http://bugs.python.org/issue18308 opened by David.Edelsohn #18309: Make python slightly more relocatable http://bugs.python.org/issue18309 opened by mathias #18312: "make distclean" deletes files under .hg directory http://bugs.python.org/issue18312 opened by eric.smith #18313: In itertools recipes repeatfunc() defines a non-keyword argume http://bugs.python.org/issue18313 opened by py.user #18314: Have os.unlink remove junction points http://bugs.python.org/issue18314 opened by Kim.Gräsman #18315: bufsize parameter not documented in 2.7.5 http://bugs.python.org/issue18315 opened by Terrel.Shumway #18316: Idle 2.7: update to simplify cross-version patches http://bugs.python.org/issue18316 opened by terry.reedy #18317: gettext: DoS via crafted Plural-Forms http://bugs.python.org/issue18317 opened by jwilk #18318: Idle: stop depending on console output http://bugs.python.org/issue18318 opened by terry.reedy #18319: gettext() cannot find translations with plural forms http://bugs.python.org/issue18319 opened by jwilk #18320: idle, pydoc search python on wrong path at make altinstall wit http://bugs.python.org/issue18320 opened by cosmicduck #18321: Multivolume support in tarfile module http://bugs.python.org/issue18321 opened by edulix #18322: test_stat nits http://bugs.python.org/issue18322 opened by pitrou #18323: 'GzipFile' object has no attribute 'extrastart' http://bugs.python.org/issue18323 opened by Laurent.Gautier Most recent 15 issues with no replies (15) ========================================== #18320: idle, pydoc search python on wrong path at make altinstall wit http://bugs.python.org/issue18320 #18319: gettext() cannot find translations with plural forms http://bugs.python.org/issue18319 #18318: Idle: stop depending on console output http://bugs.python.org/issue18318 #18307: Relative path in co_filename for zipped modules http://bugs.python.org/issue18307 #18305: [patch] Fast sum() for non-numbers http://bugs.python.org/issue18305 #18304: ElementTree gets awkward to use if there is an xmlns http://bugs.python.org/issue18304 #18302: test_multiprocessing: test.support.import_module() does not ig http://bugs.python.org/issue18302 #18300: script_helper._asert_python should set TERM='' by default. http://bugs.python.org/issue18300 #18299: Change script_helper to use universal_newlines=True in _assert http://bugs.python.org/issue18299 #18292: IDLE Improvements: Unit test for AutoExpand.py http://bugs.python.org/issue18292 #18273: Simplify calling and discovery of json test package http://bugs.python.org/issue18273 #18266: Fix test discovery for test_largefile.py http://bugs.python.org/issue18266 #18258: Fix test discovery for test_codecmaps*.py http://bugs.python.org/issue18258 #18254: Accessing attr dict at definition time of a class from a metac http://bugs.python.org/issue18254 #18243: mktime_tz documentation out-of-date http://bugs.python.org/issue18243 Most recent 15 issues waiting for review (15) ============================================= #18322: test_stat nits http://bugs.python.org/issue18322 #18321: Multivolume support in tarfile module http://bugs.python.org/issue18321 #18317: gettext: DoS via crafted Plural-Forms http://bugs.python.org/issue18317 #18315: bufsize parameter not documented in 2.7.5 http://bugs.python.org/issue18315 #18312: "make distclean" deletes files under .hg directory http://bugs.python.org/issue18312 #18309: Make python slightly more relocatable http://bugs.python.org/issue18309 #18305: [patch] Fast sum() for non-numbers http://bugs.python.org/issue18305 #18301: In itertools.chain.from_iterable() there is no cls argument http://bugs.python.org/issue18301 #18294: zlib module is not completly 64-bit safe http://bugs.python.org/issue18294 #18287: PyType_Ready() should sanity-check the tp_name field http://bugs.python.org/issue18287 #18283: shutil.which() should support bytes http://bugs.python.org/issue18283 #18279: IDLE Unit test for RstripExtension.py http://bugs.python.org/issue18279 #18273: Simplify calling and discovery of json test package http://bugs.python.org/issue18273 #18266: Fix test discovery for test_largefile.py http://bugs.python.org/issue18266 #18258: Fix test discovery for test_codecmaps*.py http://bugs.python.org/issue18258 Top 10 most discussed issues (10) ================================= #16487: Allow ssl certificates to be specified from memory rather than http://bugs.python.org/issue16487 17 msgs #17206: Py_XDECREF() expands its argument multiple times http://bugs.python.org/issue17206 15 msgs #18234: Unicodedata module should provide access to codepoint aliases http://bugs.python.org/issue18234 15 msgs #11016: Re-implementation of the stat module in C http://bugs.python.org/issue11016 14 msgs #18236: str.isspace should use the Unicode White_Space property http://bugs.python.org/issue18236 11 msgs #18264: enum.IntEnum is not compatible with JSON serialisation http://bugs.python.org/issue18264 10 msgs #17621: Create a lazy import loader mixin http://bugs.python.org/issue17621 9 msgs #9566: Compilation warnings under x64 Windows http://bugs.python.org/issue9566 8 msgs #18135: _ssl module: possible integer overflow for very long strings ( http://bugs.python.org/issue18135 8 msgs #18081: test_logging failure in WarningsTest on buildbots http://bugs.python.org/issue18081 7 msgs Issues closed (34) ================== #1542: Ship 32 and 64bit libs with MSI installer http://bugs.python.org/issue1542 closed by christian.heimes #1953: Compact int and float freelists http://bugs.python.org/issue1953 closed by christian.heimes #4610: Unicode case mappings are incorrect http://bugs.python.org/issue4610 closed by belopolsky #9369: const char* for PyObject_CallMethod and PyObject_CallFunction http://bugs.python.org/issue9369 closed by serhiy.storchaka #11390: doctest: add cmdline parameters http://bugs.python.org/issue11390 closed by r.david.murray #11454: email.message import time http://bugs.python.org/issue11454 closed by r.david.murray #13483: Use VirtualAlloc to allocate memory arenas http://bugs.python.org/issue13483 closed by loewis #14264: Comparison bug in distutils2.version http://bugs.python.org/issue14264 closed by eric.araujo #14360: email.encoders.encode_quopri doesn't work with python 3.2 http://bugs.python.org/issue14360 closed by r.david.murray #15223: datetime instances lack __module__ attribute http://bugs.python.org/issue15223 closed by belopolsky #15818: multiprocessing documentation of Process.exitcode http://bugs.python.org/issue15818 closed by sbt #16114: incorrect path in subprocess.Popen() FileNotFoundError message http://bugs.python.org/issue16114 closed by gregory.p.smith #17037: Use a test.support helper to wrap the PEP 399 boilerplate http://bugs.python.org/issue17037 closed by eric.snow #17985: multiprocessing Queue.qsize() and Queue.empty() with different http://bugs.python.org/issue17985 closed by sbt #18137: format(float, str): integer overflow for huge precision http://bugs.python.org/issue18137 closed by haypo #18143: ssl.get_default_verify_paths() http://bugs.python.org/issue18143 closed by christian.heimes #18164: Embedding Python doc incorrectly refers to LINKFORSHARED http://bugs.python.org/issue18164 closed by ned.deily #18179: SMTP.local_hostname is undocumented http://bugs.python.org/issue18179 closed by r.david.murray #18184: Add range check for %c in PyUnicode_FromFormat http://bugs.python.org/issue18184 closed by serhiy.storchaka #18220: Expand itertools.islice docstring signature to 2 lines http://bugs.python.org/issue18220 closed by python-dev #18222: os.path.abspath should accept multiple path parts and join the http://bugs.python.org/issue18222 closed by terry.reedy #18246: tkinter.Text() add a newline to the content - bug? http://bugs.python.org/issue18246 closed by terry.reedy #18260: configparser: TypeError occurs when handling errors in files w http://bugs.python.org/issue18260 closed by lukasz.langa #18277: Queue is empty right after put from the same process/thread http://bugs.python.org/issue18277 closed by sbt #18278: Clarify the loader requirements for importlib.machinery.FileFi http://bugs.python.org/issue18278 closed by brett.cannon #18282: Ugly behavior of binary and unicode handling on reading unknow http://bugs.python.org/issue18282 closed by r.david.murray #18284: Doc make html: KeyError: 'howto/advocacy' http://bugs.python.org/issue18284 closed by r.david.murray #18285: In itertools.product() add argument repeat to the docstring http://bugs.python.org/issue18285 closed by python-dev #18297: In random.sample() correct the ValueError message for negative http://bugs.python.org/issue18297 closed by mark.dickinson #18298: pythonw.exe fails with redirected stderr http://bugs.python.org/issue18298 closed by amaury.forgeotdarc #18303: json.dumps() claims numpy.ndarray and numpy.bool_ are not seri http://bugs.python.org/issue18303 closed by ethan.furman #18310: itertools.tee() can't accept keyword arguments http://bugs.python.org/issue18310 closed by rhettinger #18311: Typo in SSL documentation http://bugs.python.org/issue18311 closed by r.david.murray #1040439: Missing documentation on how to link with libpython http://bugs.python.org/issue1040439 closed by ned.deily

1 0

Classes with ordered namespaces
by Eric Snow June 27, 2013

June 27, 2013

There are two relevant class namespaces in this proposal: definition namespace and __dict__. Currently both are dicts. For class definition namespaces, I'd like to make the default an OrderedDict. With the implementation in issue16991, the change is trivial (basically 1-liners in 2 spots). This change would make it unnecessary to write a custom metaclass just for a __prepare__(). PEP 422 alleviates that problem somewhat. However, I expect OrderedDict is by far the most common type returned by __prepare__(), so having it be the default would proportionately reduce the need for people to write metaclasses or learn about the PEP 422 API. You may ask what is the point if they aren't using a metaclass. That leads to the other half of the proposal. Once I have a class, I'd like to know the definition order without needing a metaclass. Unfortunately it's not as simple as using the C OrderedDict (issue16991 again) for tp_dict, etc. That change is actually pretty trivial. However, it causes problems because the concrete C API (PyDict_*) doesn't play nice with subclasses and the concrete API is used on class __dict__ all over the place. The alternative I propose is to add __definition_order__ or similar to classes. It would be a list of the names from the definition namespace, in definition order (making use of the new default there). Having a class's __dict__ be ordered isn't important if the definition order is available somewhere. Again, using the C OrderedDict, the change to add __definition_order__ is pretty trivial. FWIW, Guido already expressed some approval[1]. -eric [1] http://mail.python.org/pipermail/python-ideas/2013-February/019704.html

4 7

Re: [Python-Dev] [Python-checkins] peps: Reject PEP 315.
by R. David Murray June 27, 2013

June 27, 2013

On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa <python-checkins(a)python.org> wrote: > - Deferred; see > + Rejected; see > + http://mail.python.org/pipermail/python-ideas/2013-June/021610.html > + > + This PEP has been deferred since 2006; see > http://mail.python.org/pipermail/python-dev/2006-February/060718.html > > Subsequent efforts to revive the PEP in April 2009 did not > meet with success because no syntax emerged that could > - compete with a while-True and an inner if-break. > + compete with the following form: > > - A syntax was found for a basic do-while loop but it found > - had little support because the condition was at the top: > + while True: > + <setup code> > + if not <condition>: > + break > + <loop body> > > - do ... while <cond>: > - <loop body> > + Users of the language are advised to use that form when a do-while > + loop would have been appropriate. Why delete the information about what was found wanting? --David

3 3

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
by Antoine Pitrou June 25, 2013

June 25, 2013

On Fri, 14 Jun 2013 07:06:49 +0200 (CEST) raymond.hettinger <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/5accb0ac8bfb > changeset: 84116:5accb0ac8bfb > branch: 2.7 > parent: 84095:ca8e86711403 > user: Raymond Hettinger <python(a)rcn.com> > date: Fri Jun 14 01:06:33 2013 -0400 > summary: > Fix comment blocks. Adjust blocksize to a power-of-two for better divmod computations. Is there any rationale for changing the heuristic from "fits in a whole number of cachelines" to "allows fast division by the blocksize"? I personally would prefer if such changes were justified a bit more than by a one-liner changeset message without any corresponding open issue. Regards Antoine.

12 26

Re: [Python-Dev] [Python-checkins] cpython (3.3): Add -b and -X options to python man page.
by Brett Cannon June 25, 2013

June 25, 2013

On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran < python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/dfead0696a71 > changeset: 84224:dfead0696a71 > branch: 3.3 > parent: 84221:0113247f894b > user: Senthil Kumaran <senthil(a)uthcode.com> > date: Wed Jun 19 22:19:46 2013 -0500 > summary: > Add -b and -X options to python man page. > Patch contributed by Corey Brune. > > files: > Misc/python.man | 22 ++++++++++++++++++---- > 1 files changed, 18 insertions(+), 4 deletions(-) > > > diff --git a/Misc/python.man b/Misc/python.man > --- a/Misc/python.man > +++ b/Misc/python.man > @@ -11,6 +11,9 @@ > .B \-B > ] > [ > +.B \-b > +] > +[ > .B \-d > ] > [ > @@ -23,14 +26,14 @@ > .B \-i > ] > [ > -.B \-m > +.B \-m > .I module-name > ] > -[ > -.B \-q > -] > .br > [ > +.B \-q > +] > +[ > .B \-O > ] > [ > @@ -60,6 +63,10 @@ > .B \-x > ] > [ > +[ > +.B \-X > +.I option > +] > .B \-? > ] > .br > @@ -105,6 +112,10 @@ > .I .py[co] > files on import. See also PYTHONDONTWRITEBYTECODE. > .TP > +.B \-b > +Issue warnings about str(bytes_instance), str(bytearray_instance) > +and comparing bytes/bytearray with str. (-bb: issue errors) > +.TP > .BI "\-c " command > Specify the command to execute (see next section). > This terminates the option list (following options are passed as > @@ -243,6 +254,9 @@ > field matches the line number, where zero matches all line numbers and > is thus equivalent to an omitted line number. > .TP > +.BI "\-X " option > +Set implementation specific option. > Should probably be "Set the implementation-specific option." > +.TP > .B \-x > Skip the first line of the source. This is intended for a DOS > specific hack only. Warning: the line numbers in error messages will > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > >

9 11

Re: [Python-Dev] [Python-checkins] cpython: Issue #18081: Workaround "./python -m test_idle test_logging" failure
by Brett Cannon June 25, 2013

June 25, 2013

This fix is still not correct as warnings.formatwarning should not be overridden, only showwarning can be. On Jun 24, 2013 6:18 PM, "victor.stinner" <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/2a9e1eb3719c > changeset: 84330:2a9e1eb3719c > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Tue Jun 25 00:17:37 2013 +0200 > summary: > Issue #18081: Workaround "./python -m test_idle test_logging" failure > > "import idlelib" should not install hooks on the warning modules, hooks > should > only be installed when IDLE is started. > > files: > Lib/idlelib/PyShell.py | 5 +++-- > Lib/idlelib/run.py | 4 +++- > 2 files changed, 6 insertions(+), 3 deletions(-) > > > diff --git a/Lib/idlelib/PyShell.py b/Lib/idlelib/PyShell.py > --- a/Lib/idlelib/PyShell.py > +++ b/Lib/idlelib/PyShell.py > @@ -61,7 +61,6 @@ > lineno, line=line)) > except OSError: > pass ## file (probably __stderr__) is invalid, warning > dropped. > - warnings.showwarning = idle_showwarning > def idle_formatwarning(message, category, filename, lineno, > line=None): > """Format warnings the IDLE way""" > s = "\nWarning (from warnings module):\n" > @@ -73,7 +72,6 @@ > s += " %s\n" % line > s += "%s: %s\n>>> " % (category.__name__, message) > return s > - warnings.formatwarning = idle_formatwarning > > def extended_linecache_checkcache(filename=None, > orig_checkcache=linecache.checkcache): > @@ -1425,6 +1423,9 @@ > def main(): > global flist, root, use_subprocess > > + warnings.showwarning = idle_showwarning > + warnings.formatwarning = idle_formatwarning > + > use_subprocess = True > enable_shell = False > enable_edit = False > diff --git a/Lib/idlelib/run.py b/Lib/idlelib/run.py > --- a/Lib/idlelib/run.py > +++ b/Lib/idlelib/run.py > @@ -40,7 +40,6 @@ > s += " %s\n" % line > s += "%s: %s\n" % (category.__name__, message) > return s > - warnings.formatwarning = idle_formatwarning_subproc > > > tcl = tkinter.Tcl() > @@ -82,6 +81,9 @@ > global exit_now > global quitting > global no_exitfunc > + > + warnings.formatwarning = idle_formatwarning_subproc > + > no_exitfunc = del_exitfunc > #time.sleep(15) # test subprocess not responding > try: > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > >

1 0