python 时间表_Python 2.5时间表

For more details about the plan for Python 2.5, see:

http://www.python.org/doc/peps/pep-0356/

The highlights are that we are hoping to put out the first alpha Real

Soon Now, hopefully in a week or two. If there''s something you really

think just must be in 2.5 and can''t wait until 2.6, now is the time to

speak up. (Actually, it was time to speak up months ago.) Send a

message to python-dev. If you have a patch or bug report outstanding

that you would like to see fixed for 2.5, add a comment to it. Patches

and bugs will continue to be worked on until final release.

We are trying to be mostly feature complete by the first alpha. This

is especially true for large C modifications. There are still a few

more Python-based modules that are likely to make it into the standard

library before alpha 2.

I''m still hoping we can get a final 2.5 out by August. Worst case, we

should have release by September. A lot more testing

(http://www.python.org/dev/buildbot/all/) has gone into this version

than in the past, I expect this to be the most stable python yet. Even

if we did happen to rip out the guts and and replace all the internals

with a new AST compiler, support for 64-bit objects (PEP 353), not to

mention support for try-except-finally (PEP 341), a new with statement

(PEP 343), and a whole lot more. :-) See the PEP for what''s to come.

It would be great to start testing now, particularly C extension

modules.

For those too lazy to hit the link, here are some more details copied

from the PEP:

Release Schedule

alpha 1: April 1, 2006 [planned]

alpha 2: April 29, 2006 [planned]

alpha 3: May 27, 2006 [planned]

beta 1: June 24, 2006 [planned]

beta 2: July 15, 2006 [planned]

rc 1: August 5, 2006 [planned]

final: August 19, 2006 [planned]

Completed features for 2.5

PEP 308: Conditional Expressions

PEP 309: Partial Function Application

PEP 314: Metadata for Python Software Packages v1.1

PEP 328: Absolute/Relative Imports

PEP 341: Unified try-except/try-finally to try-except-finally

PEP 342: Coroutines via Enhanced Generators

PEP 343: The "with" Statement

PEP 352: Required Superclass for Exceptions

PEP 353: Using ssize_t as the index type

PEP 357: Allowing Any Object to be Used for Slicing

- ASCII is the default coding

- AST-based compiler

- Access to C AST from Python through new _ast module

- Add support for reading shadow passwords

(http://python.org/sf/579435)

- any()/all() builtin truth functions

- new hashlib module add support for SHA-224, -256, -384, and -512

(replaces old md5 and sha modules)

- new cProfile module suitable for profiling long running

applications

with minimal overhead

- Fredrik Lundh''s ElementTree and cElementTree

Cheers,

n

解决方案nn******@gmail.com wrote:For more details about the plan for Python 2.5, see:

http://www.python.org/doc/peps/pep-0356/

I hope that this is not considered too off topic, but what compiler is

going to be used for the MSW version of 2.5?

If it is going to the MS Visual Studio 2005 compiler then will it be

possible to use the ''free'' Visual C++ 2005 Express Edition to build

extensions?

Thanks,

Don.

Don Taylor wrote:nn******@gmail.com wrote:For more details about the plan for Python 2.5, see:

http://www.python.org/doc/peps/pep-0356/

I hope that this is not considered too off topic, but what compiler is

going to be used for the MSW version of 2.5?

If it is going to the MS Visual Studio 2005 compiler then will it be

possible to use the ''free'' Visual C++ 2005 Express Edition to build

extensions?

I think there will be no compiler switching for a while. The previous

switch from VC 6 was in part because there was no longer any legal way

to get a VC 6.0 compiler. This round at least is sticking with the same

compiler as Python 2.4 (VC 7.0).

The new 2005 compiler flags much of the Python source with complaints

about perfectly legal ANSI C constructs, and a "clean build" is a strong

preference of the PyDev group.

--

-Scott David Daniels

sc***********@acm.org

Yes, it''s very annoying to see VC8 warnings on perfectly legal C

constructs (AFAIK even sprinf is now considered "unsafe", MS wants

everybody to use sprintf_s). But the optimisation capacities of VC8 are

really great. Maybe someone can measure the speedup?

P.S. there''s an "_CRT_SECURE_NO_DEPRECATE" flag that eliminates most of

this kind of warnings. Also, #pragma ''s can be used (although this

isn''t nice at all).

P.P.S. are there any experiments with compiling CPython with Intel''s

compiler?