Mailman 3 May 2007 - Python-Dev

Mass PEP status changes
by Guido van Rossum May 18, 2007

May 18, 2007

With the help of Neal Norwitz, Jeremy Hylton, Alex Martelli and Collin Winter, I've greatly reduced the set of open PEPs numbered less than 3000. Here's a summary. Please speak up if we've made a grave error; I take all responsibility for the final decisions. Positive Decisions (Marked Accepted or Final) --------------------------------------------- SF 237 Unifying Long Integers and Integers Zadka, GvR Marked as Final; there's no work left to be done. I 287 reStructuredText Docstring Format Goodger Status changed from Draft to Active. SA 302 New Import Hooks JvR, Moore Marked Accepted. Should this be marked Final, or is there still an unimplemented part? SF 331 Locale-Independent Float/String Conversions Reis Marked Final; this was done years ago (Python 2.3?). Negative Decisions (Rejected, Withdrawn or Deferred) ---------------------------------------------------- SW 228 Reworking Python's Numeric Model Zadka, GvR Withdrawn in favor of PEP 3141 (numeric ABCs). SR 256 Docstring Processing System Framework Goodger Rejected; seems to have run out of steam. SR 258 Docutils Design Specification Goodger Rejected; docutils is no longer slated for stdlib inclusion. SD 267 Optimized Access to Module Namespaces Hylton Deferred; no-one has had time for this. SR 268 Extended HTTP functionality and WebDAV Stein Rejected for lack of interest or progress. SD 280 Optimizing access to globals GvR Deferred; no-one has had time for this. SW 296 Adding a bytes Object Type Gilbert Was withdrawn long ago in favor of PEP 358 (the bytes object). SR 297 Support for System Upgrades Lemburg Rejected; failed to generate support. SD 323 Copyable Iterators Martelli Deferred due to lack of interest. IR 350 Codetags Elliott Rejected for lack of will to standardize. XXX lives! SR 354 Enumerations in Python Finney Rejected; not enough interest, not sufficiently Pythonic. SR 355 Path - Object oriented filesystem paths Lindqvist Rejected as being the ultimate kitchen sink. SR 754 IEEE 754 Floating Point Special Values Warnes Rejected for lack of progress. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

3 5

recursion limit in marshal
by Neal Norwitz May 18, 2007

May 18, 2007

I had a little argument with the marshal module on Windows last night, I eventually won. :-) A patch was checked in which would prevent blowing out the stack and segfaulting with this code: marshal.loads( 'c' + ('X' * 4*4) + '{' * 2**20) Originally, I didn't change the recursion limit which was 5000. (See MAX_MARSHAL_STACK_DEPTH in Python/marshal.c) This is a constant in C code that cannot be changed at runtime. The fix worked on most platforms. However it didn't on some (Windows and MIPS?), presumably due a smaller stack limit. I don't know what the stack limits are on each architecture. I dropped the limit to 4000, that still crashed. I eventually settled on 2000. Which passed in 2.6. I don't think there is a test case for the recursion limit when dumping a deeply nested object. I suppose I should add one, because that could also blow the limit too. The point of this message is to see if anyone thinks 2000 is unreasonable. It could probably be raised, but I'm not going to try it since I don't have access to a Windows box. Testing this remotely sucks. n

2 1

Official version support statement
by Barry Warsaw May 16, 2007

May 16, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This came up in a different context. I originally emailed this to the python.org admins, but Aahz rightly points out that we should first agree here that this actually /is/ our official stance. - -----snip----- We have an "official unofficial" policy of supporting only Python 2.current and 2.(current - 1), and /not/ supporting anything earlier. Do we already have an official statement to this effect on the website? The closest thing I could find was on the download page, but that's not really definitive. What do you think about adding something like the following to the top of the download page: "The Python Software Foundation officially supports the current stable major release and one prior major release. Currently, Python 2.5 and 2.4 are officially supported. Where appropriate and necessary, patches for earlier releases may be made available, but no earlier versions are officially supported by the PSF. We do not make releases of unsupported versions, although patched versions may become available through other vendors." - -Barry P.S. On re-reading this, I realize this text would need amending when Python 3.x is released, but I don't care about that right now. pdo admins: I also slightly changed the proposed text. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkM1/XEjvBPtnXfVAQJufwP9E4A7cbHyDRk0v/hONjlt3ZJ2eCtwYZL6 hlitMIBb8YxJsGNo6p1kC0KkB/DObqmCarTy8YXIM+v8j32UmEbiRmJFxexuKdVw I0EqziHnYdSkkp3cN+EGP2jahfLFVMaA2A2Ohj0o0mLGZEQU7TTF4F6U33PlooXs G6zKmDzuLT4= =BWxm -----END PGP SIGNATURE-----

10 22

marshal and ssize_t (PEP 353)
by Neal Norwitz May 16, 2007

May 16, 2007

Martin, I'm looking at Python/marshal.c and there are a lot of places that don't support sequences that are larger than would fit into size(int). I looked for marshal referenced in the PEP and didn't find anything. Was this an oversight or intentional? To give you some examples of what I mean from the code: (line 255) n = PyString_GET_SIZE(v); if (n > INT_MAX) { /* huge strings are not supported */ p->depth--; p->error = 1; return; } w_long((long)n, p); w_string(PyString_AS_STRING(v), (int)n, p); ... (line 717) n = r_long(p); if (n < 0 || n > INT_MAX) { PyErr_SetString(PyExc_ValueError, "bad marshal data"); return NULL; } v = PyTuple_New((int)n); if (v == NULL) return v; for (i = 0; i < n; i++) { v2 = r_object(p); if ( v2 == NULL ) { if (!PyErr_Occurred()) PyErr_SetString(PyExc_TypeError, "NULL object in marshal data"); Py_DECREF(v); v = NULL; break; } PyTuple_SET_ITEM(v, (int)i, v2); Also, the PEP references the ssize_t branch which no longer exists. Is it possible to reference the specific revision: 42382? Thanks, n

3 4

updated for gdbinit
by Christian Theune May 15, 2007

May 15, 2007

Hi, I tried to use gdbinit today and found that the "fragile" pystacks macro didn't work anymore. I don't know gdb very well, but this turned out to work a bit more reliably: # print the entire Python call stack define pystack set $last=0 while $sp != $last if $pc > PyEval_EvalFrame && $pc < PyEval_EvalCodeEx pyframe end set $last=$sp up-silently 1 end select-frame 0 end Just in case anybody might want to use this and update the existing gdbinit. Christian PS: I'm not subscribed to this list.

3 2

Draft PEP: Maintenance of Python Releases
by "Martin v. Löwis" May 15, 2007

May 15, 2007

This PEP attempts to formalize the existing practice, but goes beyond it in introducing security releases. The addition of security releases addresses various concerns I heard over the last year about Python being short-lived. Those concerns are typically raised by Linux distributors which see that they have to maintain Python releases much longer than python-dev does, and are now concerned about the manpower and Python expertise they need. When looking in detail, they are primarily concerned with security fixes. They will not add new features to old releases, and they can ignore bug fixes, but they cannot ignore security fixes. So what I really think they want is some form of commitment that security fixes are still considered for a much longer period of time. In discussions, people often consider "short-lived" as "shorter than five years". So the PEP proposes to produce security releases for five years after the initial release; this would mean that we are willing to make security releases for 2.3 (until July 2008) and 2.4 (until November 2009). To reduce the work-load, the PEP promises no more than one security release per branch per year (if no security fixes get contributed, no release needs to be made). Notice that this setup significantly relies on *no* bug fixes (other than security fixes) being committed to a branch after the final bugfix release. Addition of bug fixes would require much more extensive testing, with release candidates and everything, so it is essential that there are very very few new patches in each security release. Please let me know what you think. Regards, Martin PEP: XX Title: Maintenance of Python Releases Version: $Revision$ Last-Modified: $Date$ Author: Martin v. Löwis <martin(a)v.loewis.de> Discussions-To: <python-dev(a)python.org> Status: Draft Type: Process Content-Type: text/x-rst Created: 12-May-2005 Abstract ======== This PEP defines the policy for the maintenance of release branches for Python. Overview ======== The Python core developers maintain two major branches at any point in time: the trunk, which will eventually become the next major release, and the current release branch, from which bug-fix releases are made. As a special case, the number of branches may duplicate while Python 2.x and Python 3.x is developed in parallel. Older releases of Python see no regular maintenance, however, security flaws will be fixed in older releases, eventually resulting in a security release. Major Releases ============== Major releases are numbered x.y (despite the .y being commonly named "minor" release in other projects). The release process is described in PEP 101. Major releases should be produced roughly every 18 months, but the actual release frequency may vary significantly. With a major release x.y, this release becomes the current release. For the previous current release (x.(y-1)), a final bug fix release is produced shortly after the x.y release. Bugfix Releases =============== Bug fix releases (numbered x.y.z) are described in PEP 6. As stated there, they may only include bug fixes (no new features), and they are produced typically every six months. Bug fixes should be committed to the release branch as an ongoing activity (e.g. along with fixing them in the trunk), rather than being backported just before the release. After the final bug fix release for a branch has been made, the branch becomes unmaintained except for security fixes. No bug fix patches must be applied to the branch. Security Releases ================= As users operate Python releases long after the release branch has become unmaintained, they still like to see security patches fixed. The Python source repository can act as a repository for security fixes even after the branch has become unmaintained. Users wishing to contribute security patches must clearly indicate that a certain patch is a security patch, and to what branches they want to see it applied. Commit messages of security patches on unmaintained branches must indicate that the commit was done for security reasons; an explicit description of potential exploits should be avoided. A security fix must not risk the releasability of the branch, i.e. the maintenance branch should be in a shape to produce a release out of it as-is at all times. >From time to time, security releases will be made from an unmaintained branch. A security release will be a source-only release (i.e. no Windows or Macintosh binaries are provided); they will follow the numbering of minor releases (i.e. x.y.z). Security releases should be made at most one year after a security patch has been committed to the branch; users wishing to deploy security patches earlier can safely export the maintenance branch, or otherwise incorporate all committed security fixes into their code base. Security releases should be made for a period of five years after the initial major release. 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 coding: utf-8 End:

6 19

Functools Defaults (was Python-ideas parameter omit)
by Aaron Brady May 15, 2007

May 15, 2007

> -----Original Message----- > From: Steven Bethard [mailto:steven.bethard@gmail.com] > Sent: Tuesday, May 15, 2007 1:54 AM > > On 5/15/07, Aaron Brady <castironpi(a)comcast.net> wrote: > > You might be able to get away without a PEP, but you'll definitely > need to post an implementation patch to the bug tracker > (http://sourceforge.net/tracker/?group_id=5470&atid=105470). Once > you've posted your implementation, you should send an email to > python-dev asking folks what they think about it. Be sure to give > some code examples that using this decorator would simplify. Code with proposal are in SourceForge [ 1719222 ] new functools. Python feature Functools gains a new decorator. `Defaults' allows its caller to placehold non-None defaults; it becomes unnecessary to know the value a place defaults to. It might be useful in cases where you want the calling signature to look alike for a group of dispatched functions and the added overhead the decorator adds isn't a problem. But you probably wouldn't want that overhead all the time, so having it as an optional decorator would be good. -Ron Adam What -do- you think about it?

2 1

Re: [Python-Dev] New operations in Decimal
by Raymond Hettinger May 14, 2007

May 14, 2007

> The only rationale I can think of for such a thing is > that maybe they're trying to accommodate the possibility > of a machine built entirely around a hardware implementation > of the spec, that doesn't have any other way of doing > bitwise logical operations. If that's the case, then Python > clearly has no need for it. Doesn't matter. My intention for the module is to be fully compliant with the spec and all of its tests. Code written in other languages which support the spec should expect to be transferrable to Python and run exactly as they did in the original language. The module itself makes that promise: "this module should be kept in sync with the latest updates of the IBM specification as it evolves. Those updates will be treated as bug fixes (deviation from the spec is considered a compatibility, usability bug)" If I still have any say in the matter, please consider this a pronouncement. Tim, if you're listening, please chime in. Raymond

4 3

\u and \U escapes in raw unicode string literals
by Guido van Rossum May 14, 2007

May 14, 2007

I just discovered that, in all versions of Python as far back as I have access to (2.0), \uXXXX escapes are interpreted inside raw unicode strings. Thus: >>> a = ur"\u1234" >>> len(a) 1 >>> Contrast this with: >>> a = ur"\x12" >>> len(a) 4 >>> The \U escape has the same behavior, in versions that support it. Does anyone remember why it is done this way? The reference manual describes this behavior, but doesn't give an explanation: """ When an "r" or "R" prefix is used in conjunction with a "u" or "U" prefix, then the \uXXXX and \UXXXXXXXX escape sequences are processed while all other backslashes are left in the string. For example, the string literal ur"\u0062\n" consists of three Unicode characters: `LATIN SMALL LETTER B', `REVERSE SOLIDUS', and `LATIN SMALL LETTER N'. Backslashes can be escaped with a preceding backslash; however, both remain in the string. As a result, \uXXXX escape sequences are only recognized when there are an odd number of backslashes. """ -- --Guido van Rossum (home page: http://www.python.org/~guido/)

12 33

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser May 14, 2007

May 14, 2007

Patch / Bug Summary ___________________ Patches : 362 open ( +2) / 3766 closed ( +6) / 4128 total ( +8) Bugs : 968 open ( -3) / 6692 closed ( +9) / 7660 total ( +6) RFE : 256 open ( -1) / 286 closed ( +4) / 542 total ( +3) New / Reopened Patches ______________________ Fix off-by-one error in Modules/socketmodule.c (2007-05-06) CLOSED http://python.org/sf/1713797 opened by Bryan Østergaard Patch for PEP 3109 (2007-05-06) http://python.org/sf/1713889 opened by wpy os.linesep needs clarification (2007-05-07) CLOSED http://python.org/sf/1714700 opened by Gabriel Genellina x64 clean compile patch for _ctypes (2007-05-09) http://python.org/sf/1715718 opened by Kristján Valur "Really print?" Dialog (2007-05-11) http://python.org/sf/1717170 opened by Tal Einat textView code cleanup (2007-05-13) http://python.org/sf/1718043 opened by Tal Einat PEP 3123 implementation (2007-05-13) http://python.org/sf/1718153 opened by Martin v. Löwis Patches Closed ______________ Fix off-by-one error in Modules/socketmodule.c (2007-05-06) http://python.org/sf/1713797 closed by gbrandl make range be xrange (2006-04-18) http://python.org/sf/1472639 closed by nnorwitz xrange that supports longs, etc (2006-08-24) http://python.org/sf/1546078 closed by nnorwitz os.linesep needs clarification (2007-05-08) http://python.org/sf/1714700 closed by gbrandl PEP 3132: extended unpacking (2007-05-02) http://python.org/sf/1711529 closed by gbrandl Bastion and rexec message out-of-date (2007-04-12) http://python.org/sf/1698951 closed by gbrandl New / Reopened Bugs ___________________ smtplib starttls() didn't do TLS Close Notify when quit() (2007-05-07) CLOSED http://python.org/sf/1713993 opened by AndCycle Multiple re.compile flags cause error (2007-05-06) CLOSED http://python.org/sf/1713999 opened by Saul Spatz character set in Japanese on Ubuntu distribution (2007-05-04) http://python.org/sf/1713252 reopened by cgrell Universal line ending mode duplicates all line endings (2007-05-07) CLOSED http://python.org/sf/1714381 opened by Geoffrey Bache subprocess.py problems errors when calling cmd.exe (2007-05-07) http://python.org/sf/1714451 opened by tzellman python throws an error when unpacking bz2 file (2007-05-08) http://python.org/sf/1714773 opened by runnig datetime.date won't accept 08 or 09 as valid days. (2007-05-08) CLOSED http://python.org/sf/1715302 opened by Erik Wickstrom Const(None) in compiler.ast.Return.value (2007-05-09) http://python.org/sf/1715581 opened by Ali Gholami Rudi Destructor behavior faulty (2007-05-12) http://python.org/sf/1717900 opened by Wolf Rogner posixpath and friends have uses that should be documented (2007-05-13) http://python.org/sf/1718017 opened by Gabriel de Perthuis Bugs Closed ___________ smtplib starttls() didn't do TLS Close Notify when quit() (2007-05-07) http://python.org/sf/1713993 deleted by andcycle Multiple re.compile flags cause error (2007-05-07) http://python.org/sf/1713999 closed by gbrandl Universal line ending mode duplicates all line endings (2007-05-07) http://python.org/sf/1714381 closed by gbrandl datetime.date won't accept 08 or 09 as valid days. (2007-05-08) http://python.org/sf/1715302 closed by fdrake Segfaults on memory error (2007-04-10) http://python.org/sf/1697916 closed by gbrandl types.InstanceType is missing but used by pydoc (2007-04-10) http://python.org/sf/1697782 closed by gbrandl improving distutils swig support - documentation (2004-10-14) http://python.org/sf/1046945 closed by gbrandl New / Reopened RFE __________________ Expose callback API in readline module (2007-05-06) http://python.org/sf/1713877 opened by strank if something as x: (2007-05-07) http://python.org/sf/1714448 opened by k0wax RFE Closed __________ commands module (2007-05-06) http://python.org/sf/1713624 closed by gbrandl additions to commands lib (2003-11-11) http://python.org/sf/840034 closed by gbrandl A large block of commands after an "if" cannot be (2003-03-28) http://python.org/sf/711268 closed by gbrandl Please add .bz2 in encodings_map (in the module mimetypes) (2007-04-25) http://python.org/sf/1707693 closed by gbrandl

1 0