Python 2.5 Schedule

N

nnorwitz

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
 
D

Don Taylor

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

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

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.
 
S

Scott David Daniels

Don said:
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?
Click to expand...

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.
 
G

Gregory Petrosyan

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?
 
S

Scott David Daniels

Gregory said:
P.P.S. are there any experiments with compiling CPython with Intel's
compiler?
Click to expand...
Yup, the (older) Intel compiler was quite effective for 2,2 and 2.3
(at least), and I think at least one distro was built with it.
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Pekka said:
what I would like to see in (www.python.org) is
Windows installation package (*.msi)
compiled with option "--enable-unicode=ucs4".
See http://www.xml.com/pub/a/2005/06/15/py-xml.html
Click to expand...

Just enabling that option is not enough: the resulting
binary likely crashes. In addition to changing the
type of Py_UNICODE, you also need change all calls to
Microsoft API that expects UCS-2 (i.e. all *W API).

Contributions are welcome.

Regards,
Martin
 
D

Don Taylor

Scott said:
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).
Click to expand...

Scott:

Admittedly I did not spend long looking at the MS web-site, but I could
not find anywhere where I could buy a Visual Studio C++ compiler earlier
than the 2005 edition - and then at breathtaking prices. Amazon's
second tier retailers carry a very few new and used editions, but Amazon
only carries the 2005 edition, so ...

Even if you can find Visual .NET 2003 somewhere, somehow today then will
it still be available throughout the lifetime of Python 2.5?

Erm... MinGW?

Don.
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Ben said:
Er? How did this happen?

To be specific, what about all the movement toward UTF-8?
Click to expand...

See PEP 263. ASCII is the default encoding for source code;
if you want to use UTF-8 in source code, either put

# -*- coding: utf-8 -*-

into the file, or start the file with the UTF-8 signature
(if your editor supports that).

Regards,
Martin
 
D

Don Taylor

Ravi said:
http://msdn.microsoft.com/visualc/vctoolkit2003/
Free.
Click to expand...
True, but 'The Microsoft Toolkit Compiler doesn't come out-of-the-box
with everything you need to compile extensions.' see:

http://www.vrplumber.com/programming/mstoolkit/

If you are going ahead with the VC 7.1 Toolkit compiler then is
distutils going be modified to support it?

Do you think that the 7.1 toolkit compiler will be available a year from
now? MS could replace it with a VC 8.0 version of the toolkit compiler.

Don.
 
R

Ravi Teja

Only MS can answer those questions.

Even though, Python on Windows is compiled with VC++, you can still use
Mingw32 to compile extensions. There are some articles floating around
on how to do this and I did try it successfully in the past. Please
note that I am not advocating either compiler. Just noting workarounds.
I like VC for the IDE and Mingw32 for since I don't have to jump
through hoops to compile most of the open source code.

I wonder if I can cross-compile extensions from Linux. It's a lot
easier to get dependencies with a package manager.
 
T

Terry Reedy

Ant said:
Looks like some good new stuff coming along. Does anyone know what's
happened to the path PEP (http://www.python.org/doc/peps/pep-0355/) - I
thought I'd seen somewhere that that was originally planned for 2.5...
Click to expand...

It is still being discussed and has not been accepted. Latest revision was
just 2 weeks ago and open issues are at bottom. There is the broad problem
that it mostly just rearranges existing functionality (even if for the
better) and would create two ways to do everything it does, since the
existing modules and functions could not disappear until 3.0.

tjr
 
P

Peter Hansen

Terry said:
It is still being discussed and has not been accepted. Latest revision was
just 2 weeks ago and open issues are at bottom. There is the broad problem
that it mostly just rearranges existing functionality (even if for the
better) and would create two ways to do everything it does, since the
existing modules and functions could not disappear until 3.0.
Click to expand...

And for those who are frustrated with others not seeing that it is
precisely the current (scattered) arrangement of the existing
functionality that is the issue, I say just use Jason Orendorff's
path.py as-is. It's simple, it works, it's available now.

-Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

RELEASED Python 2.5 (beta 1) 0
RELEASED Python 2.5 (alpha 2) 0
[RELEASED] Python 3.4.0 release candidate 3 0
[RELEASED] Python 3.4.0a4 0
[RELEASED] Python 3.4.0a2 0
RELEASED Python 2.5 (alpha 1) 0
[RELEASED] Python 3.4.0 0
[RELEASED] Python 3.4.0 release candidate 1 0

Members online

Total: 50 (members: 2, guests: 48)
Robots: 439

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top