Movatterモバイル変換


[0]ホーム

URL:


Following system colour schemeSelected dark colour schemeSelected light colour scheme

Python Enhancement Proposals

PEP 200 – Python 2.0 Release Schedule

Author:
Jeremy Hylton <jeremy at alum.mit.edu>
Status:
Final
Type:
Informational
Topic:
Release
Created:
12-Jul-2000
Python-Version:
2.0
Post-History:


Table of Contents

Introduction

This PEP describes the Python 2.0 release schedule, tracking thestatus and ownership of the major new features, summarizes discussionsheld in mailing list forums, and provides URLs for furtherinformation, patches, and other outstanding issues. The CVS revisionhistory of this file contains the definitive historical record.

Release Schedule

[revised 5 Oct 2000]

  • 26-Sep-2000: 2.0 beta 2
  • 9-Oct-2000: 2.0 release candidate 1 (2.0c1)
  • 16-Oct-2000: 2.0 final

Previous milestones

  • 14-Aug-2000: All 2.0 PEPs finished / feature freeze
  • 5-Sep-2000: 2.0 beta 1

What is release candidate 1?

We believe that release candidate 1 will fix all known bugs that weintend to fix for the 2.0 final release. This release should be a bitmore stable than the previous betas. We would like to see even morewidespread testing before the final release, so we are producing thisrelease candidate. The final release will be exactly the same unlessany show-stopping (or brown bag) bugs are found by testers of therelease candidate.

Guidelines for submitting patches and making changes

Use good sense when committing changes. You should know what we meanby good sense or we wouldn’t have given you commit privileges <0.5wink>. Some specific examples of good sense include:

  • Do whatever the dictator tells you.
  • Discuss any controversial changes on python-dev first. If you geta lot of +1 votes and no -1 votes, make the change. If you get asome -1 votes, think twice; consider asking Guido what he thinks.
  • If the change is to code you contributed, it probably makes sensefor you to fix it.
  • If the change affects code someone else wrote, it probably makessense to ask him or her first.
  • You can use the SF Patch Manager to submit a patch and assign it tosomeone for review.

Any significant new feature must be described in a PEP and approvedbefore it is checked in.

Any significant code addition, such as a new module or large patch,must include test cases for the regression test and documentation. Apatch should not be checked in until the tests and documentation areready.

If you fix a bug, you should write a test case that would have caughtthe bug.

If you commit a patch from the SF Patch Manager or fix a bug from theJitterbug database, be sure to reference the patch/bug number in theCVS log message. Also be sure to change the status in the patchmanager or bug database (if you have access to the bug database).

It is not acceptable for any checked in code to cause the regressiontest to fail. If a checkin causes a failure, it must be fixed within24 hours or it will be backed out.

All contributed C code must be ANSI C. If possible check it with twodifferent compilers, e.g. gcc and MSVC.

All contributed Python code must follow Guido’s Python style guide.http://www.python.org/doc/essays/styleguide.html

It is understood that any code contributed will be released under anOpen Source license. Do not contribute code if it can’t be releasedthis way.

Failing test cases need to get fixed

We need to resolve errors in the regression test suite quickly.Changes should not be committed to the CVS tree unless the regressiontest runs cleanly with the changes applied. If it fails, there may bebugs lurking in the code. (There may be bugs anyway, but that’sanother matter.) If the test cases are known to fail, they serve nouseful purpose.

testcaseplatformdatereported------------------------------test_mmapWinME03-Sep-2000Windows2b1p2prelease[04-Sep-2000timreportedbyAudunS.Rundemailto:audun@mindspring.comthemmapconstructorfailsw/WindowsError:[Errno6]ThehandleisinvalidsincetherearenoreportsofthisfailingonotherflavorsofWindows,thislooksliketobeanMEbug]

Open items – Need to be resolved before 2.0 final release

Decide whether cycle-gc should be enabled by default.

Resolve compatibility issues between core xml package and the XML-SIGXML package.

Update Tools/compiler so that it is compatible with listcomprehensions, import as, and any other new language features.

Improve code coverage of test suite.

Finish writing the PEPs for the features that went out with 2.0b1(!sad, but realistic – we’ll get better with practice).

Major effort to whittle the bug database down to size. I’ve (tim)seen this before: if you can keep all the open bugs fitting on onescreen, people will generally keep it that way. But let it slobberover a screen for a month, & it just goes to hell (no “visibleprogress” indeed!).

Accepted and in progress

  • Currently none left. [4-Sep-2000 guido]

Open: proposed but not accepted or rejected

  • There are a number of open patches again. We need to clear theseout soon.

Previously failing test cases

If you find a test bouncing between this section and the previous one,the code it’s testing is in trouble!

test case         platform    date reported---------         --------    -------------test_fork1        Linux       26-Jul-2000    [28-aug-2000 fixed by cgw; solution is to create copies of    lock in child process]    [19-Aug-2000 tim     Charles Waldman whipped up a patch to give child processes a new     "global lock":     http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470     While this doesn't appear to address the symptoms we *saw*, it     *does* so far appear to be fixing the failing cases anyway    ]test_parser       all         22-Aug-2000test_posixpath    all         22-Aug-2000test_popen2       Win32       26-Jul-2000    [31-Aug-2000 tim     This died again, but for an entirely different reason:  it uses a     dict to map file pointers to process handles, and calls a dict     access function during popen.close().  But .close releases threads,     which left the internal popen code accessing the dict without a     valid thread state.  The dict implementation changed so that's no     longer accepted.  Fixed by creating a temporary thread state in the     guts of popen's close routine, and grabbing the global lock with     it for the duration]    [20-Aug-2000 tim     changed the popen2.py _test function to use the "more" cmd     when os.name == "nt".  This makes test_popen2 pass under     Win98SE.     HOWEVER, the Win98 "more" invents a leading newline out     of thin air, and I'm not sure that the other Windows flavors     of "more" also do that.     So, somebody please try under other Windows flavors!    ]    [still fails 15-Aug-2000 for me, on Win98 - tim         test test_popen2 crashed -- exceptions.AssertionError :     The problem is that the test uses "cat", but there is     no such thing under Windows (unless you install it).     So it's the test that's broken here, not (necessarily)     the code.    ]test_winreg        Win32      26-Jul-2000    [works 15-Aug-2000 for me, on Win98 - tim]test_mmap          Win32      26-Jul-2000    [believe that was fixed by Mark H.]    [works 15-Aug-2000 for me, on Win98 - tim]test_longexp      Win98+?     15-Aug-2000    [fails in release build,     passes in release build under verbose mode but doesn't         look like it should pass,     passes in debug build,     passes in debug build under verbose mode and looks like         it should pass    ]    [18-Aug-2000, tim:  can't reproduce, and nobody else     saw it.  I believe there *is* a subtle bug in     regrtest.py when using -v, and I'll pursue that,     but can't provoke anything wrong with test_longexp     anymore; eyeballing Fred's changes didn't turn up     a suspect either     19-Aug-2000, tim: the "subtle bug" in regrtest.py -v is     actually a feature:  -v masks *some* kinds of failures,     since it doesn't compare test output with the canned     output; this is what makes it say "test passed" even     in some cases where the test fails without -v    ]test_winreg2      Win32       26-Jul-2000    [20-Aug-2000 tim - the test has been removed from the project]    [19-Aug-2000 tim     This test will never work on Win98, because it's looking for     a part of registry that doesn't exist under W98.     The module (winreg.py) and this test case will be removed     before 2.0 for other reasons, though.    ]    [still fails 15-Aug-2000 for me, on Win98 - tim     test test_winreg2 failed -- Writing: 'Test Failed: testHives',     expected: 'HKEY_PERFORMANCE_DATA\012'    ]

Open items – completed/fixed

[4-Sep-2000 guido: Fredrik finished this on 1-Sep]* PyErr_Format - Fredrik Lundh  Make this function safe from buffer overflows.[4-Sep-2000 guido: Fred has added popen2, popen3 on 28-Sep]Add popen2 support for Linux -- Fred Drake[4-Sep-2000 guido: done on 1-Sep]Deal with buffering problem with SocketServer[04-Sep-2000 tim:  done; installer runs; w9xpopen not an issue][01-Sep-2000 tim:  make a prerelease available]Windows ME:  Don't know anything about it.  Will the installereven run?  Does it need the w9xpopen hack?[04-Sep-2000 tim:  done; tested on several Windows flavors now][01-Sep-2000 tim:  completed but untested except on Win98SE]Windows installer:  If HKLM isn't writable, back off to HKCU (soPython can be installed on NT & 2000 without admin privileges).[01-Sep-200 tim - as Guido said, runtime code in posixmodule.c doesn't call this on NT/2000, so no need to avoid installing it everywhere. Added code to the installer *to* install it, though.]Windows installer:  Install w9xpopen.exe only under Win95/98.[23-Aug-2000 jeremy - tim reports "completed recently"]Windows:  Look for registry info in HKCU before HKLM - MarkHammond.[20-Aug-2000 tim - done]Remove winreg.py and test_winreg2.py.  Paul Prescod (the author)now wants to make a registry API more like the MS .NET API.  Unclearwhether that can be done in time for 2.0, but, regardless, if welet winreg.py out the door we'll be stuck with it forever, and noteven Paul wants it anymore.[24-Aug-2000 tim+guido - done]Win98 Guido:  popen is hanging on Guido, and even freezing thewhole machine.  Was caused by Norton Antivirus 2000 (6.10.20) onWindows 9x.  Resolution: disable virus protection.

Accepted and completed

  • Change meaning of x escapes -PEP 223 - Fredrik Lundh
  • Add U1234678 escapes in u”” strings - Fredrik Lundh
  • Support for opcode arguments >2**16 - Charles Waldman SF Patch100893
  • “import as” - Thomas Wouters Extend the ‘import’ and ‘from …import’ mechanism to enable importing a symbol as another name.(Without adding a new keyword.)
  • List comprehensions - Skip Montanaro Tim Peters still needs to doPEP.
  • Restore old os.path.commonprefix behavior Do we have test cases thatwork on all platforms?
  • Tim O’Malley’s cookie module with good license
  • Lockstep iteration (“zip” function) - Barry Warsaw
  • SRE - Fredrik Lundh [at least Ithink it’s done, as of15-Aug-2000 - tim]
  • Fix xrange printing behavior - Fred Drake Remove the tp_printhandler for the xrange type; it produced a list display instead of‘xrange(…)’. The new code produces a minimal call to xrange(),enclosed in (...*N) when N != 1. This makes the repr() morehuman readable while making it do what reprs are advertised asdoing. It also makes the xrange objects obvious when working in theinteractive interpreter.
  • Extended print statement - Barry WarsawPEP 214SF Patch #100970http://sourceforge.net/patch/?func=detailpatch&patch_id=100970&group_id=5470
  • interface to poll system call - Andrew Kuchling SF Patch 100852
  • Augmented assignment - Thomas Wouters Add += and family, plus Pythonand C hooks, and API functions.
  • gettext.py module - Barry Warsaw

Postponed

  • Extended slicing on lists - Michael Hudson Make lists (and otherbuiltin types) handle extended slices.
  • Compression of Unicode database - Fredrik Lundh SF Patch 100899 Atleast for 2.0b1. May be included in 2.0 as a bug fix.
  • Range literals - Thomas Wouters SF Patch 100902 We ended up having alot of doubt about the proposal.
  • Eliminated SET_LINENO opcode - Vladimir Marangozov Smalloptimization achieved by using the code object’s lnotab instead ofthe SET_LINENO instruction. Uses code rewriting technique (thatGuido’s frowns on) to support debugger, which uses SET_LINENO.

    http://starship.python.net/~vlad/lineno/ for (working at the time)patches

    Discussions on python-dev:

  • test harness for C code - Trent Mick

Rejected

  • ‘indexing-for’ - Thomas Wouters Special syntax to give Python codeaccess to the loop-counter in ‘for’ loops. (Without adding a newkeyword.)

Source:https://github.com/python/peps/blob/main/peps/pep-0200.rst

Last modified:2025-02-01 08:59:27 GMT


[8]ページ先頭

©2009-2025 Movatter.jp