Python 2.5 Schedule

4 views
Skip to first unread message

nnor...@gmail.com

unread,
Mar 18, 2006, 2:40:00 AM3/18/06
to
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

Don Taylor

unread,
Mar 18, 2006, 2:46:59 PM3/18/06
to pytho...@python.org
nnor...@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.

Scott David Daniels

unread,
Mar 18, 2006, 4:31:08 PM3/18/06
to

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
scott....@acm.org

Gregory Petrosyan

unread,
Mar 19, 2006, 6:48:44 AM3/19/06
to
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?

Pekka Niiranen

unread,
Mar 19, 2006, 8:07:45 AM3/19/06
to
Hi,

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

-pekka-

Scott David Daniels

unread,
Mar 19, 2006, 10:06:22 AM3/19/06
to
Gregory Petrosyan wrote:
> P.P.S. are there any experiments with compiling CPython with Intel's
> compiler?
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.

"Martin v. Löwis"

unread,
Mar 19, 2006, 10:11:09 AM3/19/06
to Pekka Niiranen

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

Don Taylor

unread,
Mar 19, 2006, 7:54:57 PM3/19/06
to pytho...@python.org
Scott David Daniels wrote:

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

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.

Ravi Teja

unread,
Mar 19, 2006, 11:01:48 PM3/19/06
to

Ben Finney

unread,
Mar 20, 2006, 12:20:34 AM3/20/06
to pytho...@python.org
"nnor...@gmail.com" <nnor...@gmail.com> writes:

> For more details about the plan for Python 2.5, see:
> http://www.python.org/doc/peps/pep-0356/

Thanks for bringing attention to this.

> - ASCII is the default coding

Er? How did this happen?

To be specific, what about all the movement toward UTF-8?

--
\ "I always wanted to be somebody. I see now that I should have |
`\ been more specific." -- Lily Tomlin |
_o__) |
Ben Finney

"Martin v. Löwis"

unread,
Mar 20, 2006, 3:31:04 AM3/20/06
to
Ben Finney wrote:
>> - ASCII is the default coding
>
> Er? How did this happen?
>
> To be specific, what about all the movement toward UTF-8?

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

Don Taylor

unread,
Mar 20, 2006, 10:24:04 AM3/20/06
to pytho...@python.org
Ravi Teja wrote:
> http://msdn.microsoft.com/visualc/vctoolkit2003/
> Free.
>
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.

Ravi Teja

unread,
Mar 20, 2006, 2:53:51 PM3/20/06
to
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.

Tim Peters

unread,
Mar 20, 2006, 8:04:49 PM3/20/06
to pytho...@python.org
> For more details about the plan for Python 2.5, see:
>
> http://www.python.org/doc/peps/pep-0356/

Looks like links to PEPs are completely hosed at the moment. For
example, the link above displays an empty directory, and

http://www.python.org/doc/peps

displays a directory full of empty directories.

Terry Reedy

unread,
Mar 20, 2006, 10:57:49 PM3/20/06
to pytho...@python.org

"Tim Peters" <tim.p...@gmail.com> wrote in message
news:1f7befae0603201704pdd...@mail.gmail.com...

>> For more details about the plan for Python 2.5, see:
>>
>> http://www.python.org/doc/peps/pep-0356/
>
> Looks like links to PEPs are completely hosed at the moment. For
> example, the link above displays an empty directory, and
>
> http://www.python.org/doc/peps
>
> displays a directory full of empty directories.

Back up now, at least for me.

tjr

Ant

unread,
Mar 21, 2006, 4:10:19 AM3/21/06
to
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...

--
Ant...

Terry Reedy

unread,
Mar 21, 2006, 1:14:01 PM3/21/06
to pytho...@python.org

"Ant" <ant...@gmail.com> wrote in message
news:1142932219.9...@g10g2000cwb.googlegroups.com...

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

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

Peter Hansen

unread,
Mar 21, 2006, 5:47:59 PM3/21/06
to pytho...@python.org
Terry Reedy wrote:
> "Ant" <ant...@gmail.com> wrote in message
> news:1142932219.9...@g10g2000cwb.googlegroups.com...
>
>>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...
>
> 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.

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

Reply all
Reply to author
Forward
0 new messages