Python 2.5 Schedule
nnor...@gmail.com
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
> 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
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
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
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
> P.P.S. are there any experiments with compiling CPython with Intel's
> compiler?
(at least), and I think at least one distro was built with it.
"Martin v. Löwis"
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
> 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
Ben Finney
> 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"
>> - 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
> 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
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
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
"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/
>
> 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
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
"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
> "Ant" <ant...@gmail.com> wrote in message
> news:1142932219.9...@g10g2000cwb.googlegroups.com...
>
>>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...
>
> 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