RELEASED Python 2.3.4, release candidate 1

[Anthony Baxter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.4 (release candidate 1).

Python 2.3.4 is a bug-fix release. See the release notes at the website
(also available as Misc/NEWS in the source distribution) for details of
the bugs squished in this release.

Assuming no major problems crop up, a final release of Python 2.3.4
will follow late next week.

For more information on Python 2.3.4, including download links for
various platforms, release notes, and known issues, please see:

~ http://www.python.org/2.3.4

Highlights of this new release include:

~ - Bug fixes. According to the release notes, more than 20 bugs
~ have been fixed, including a couple of bugs that could cause
~ Python to crash. These were discovered by Zope3.

Highlights of the previous major Python release (2.3) are available
from the Python 2.3 page, at

~ http://www.python.org/2.3/highlights.html

Enjoy the new release,
Anthony

Anthony Baxter
(e-mail address removed)
Python Release Manager
(on behalf of the entire python-dev team)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAo3yTDt3F8mpFyBYRAicdAJwOngKitELJ25u3oCW+iQcc581wbQCgh1Ah
f/Ci2omZVG7p63xY9cfZiSw=
=e3Rv
-----END PGP SIGNATURE-----

 

[Irmen de Jong]

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.4 (release candidate 1).

Cool! Thanks.

I've got a question though, I've submitted a patch for a bug in
SimpleHTTPServer.py in december last year;
http://sourceforge.net/tracker/?func=detail&aid=839496&group_id=5470&atid=305470

SimpleHTTPServer reports a wrong content-length of text files on windows
The bug is still there in this release. Any change of getting my patch applied?


--Irmen de Jong.

 

[Aahz]

Cool! Thanks.

I've got a question though, I've submitted a patch for a bug in
SimpleHTTPServer.py in december last year;
http://sourceforge.net/tracker/?func=detail&aid=839496&group_id=5470&atid=305470

SimpleHTTPServer reports a wrong content-length of text files on
windows The bug is still there in this release. Any change of getting
my patch applied?

Not at this point, sorry. It's generally assumed that people who care
about the progress of release schedules are subscribed to python-dev;
perhaps that assumption should be challenged.

 

[Irmen de Jong]

Not at this point, sorry. It's generally assumed that people who care
about the progress of release schedules are subscribed to python-dev;
perhaps that assumption should be challenged.

That's unfortunate, I reported it even before 2.3.3 was released.
Doesn't anybody use SimpleHTTPServer then?

Well, more luck next time, I guess.

--Irmen

P.S. I don't really see why you mentioned python-dev, are you saying
that bugs and patches have more chance of being included in a new
Python version if the submitter is subscribed to python-dev and also
announces the bugs/patches there?

 

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

P.S. I don't really see why you mentioned python-dev, are you saying
that bugs and patches have more chance of being included in a new
Python version if the submitter is subscribed to python-dev and also
announces the bugs/patches there?

Patches have a larger chance to get included if they are reviewed.
For the last few years, we have been short of reviewers, so patches
have little chance to get included, period. People submitting patches
might consider helping the process beyond submitting patches, e.g.
by reviewing patches of other people. E.g. review 10 or so patches,
put your comments into them, and then suggest approval or rejection
on python-dev. Then, somebody (perhaps yours truly) might check
bulk-close patches if he agrees with the review. If any submitter
of a patch would review 10 other patches, there would be no backlog.

Regards,
Martin

 

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

P.S. I don't really see why you mentioned python-dev, are you saying
that bugs and patches have more chance of being included in a new
Python version if the submitter is subscribed to python-dev and also
announces the bugs/patches there?

Patches have a larger chance to get included if they are reviewed.
For the last few years, we have been short of reviewers, so patches
have little chance to get included, period. People submitting patches
might consider helping the process beyond submitting patches, e.g.
by reviewing patches of other people. E.g. review 10 or so patches,
put your comments into them, and then suggest approval or rejection
on python-dev. Then, somebody (perhaps yours truly) might check
bulk-close patches if he agrees with the review. If any submitter
of a patch would review 10 other patches, there would be no backlog.

Regards,
Martin

 

[Irmen de Jong]

Patches have a larger chance to get included if they are reviewed.
For the last few years, we have been short of reviewers, so patches
have little chance to get included, period.

Fair enough.

If any submitter
of a patch would review 10 other patches, there would be no backlog.

Would it be an idea to 'announce' this on the newsgroup, a certain
period before releasing a new Python version? Like for instance:
"There are at least N patches in need of reviews. Please review the
patches to improve their chance of getting included in the next
python version, due in X weeks".... to bring it to people's attention?
Just an idea.

In the meantime, I'll see what I can do

Regards,

Irmen de Jong.

 

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

Would it be an idea to 'announce' this on the newsgroup, a certain
period before releasing a new Python version?

I announce statements like this every year or so. Sometimes, this
causes a burst of help, but unfortunately, nothing sustainable.

"There are at least N patches in need of reviews. Please review the
patches to improve their chance of getting included in the next
python version, due in X weeks".... to bring it to people's attention?

There are constantly more than 200 patches that need review; starting
with that when the next release approaches is often too late. IOW,
many of the pending patches won't make it in 2.4.0, and can't make it
into any 2.4.x release because of backwards compatibility issues.
Targeting them at 2.5.0 makes a tight schedule already...

Regards,
Martin

 

[Aahz]

P.S. I don't really see why you mentioned python-dev, are you saying
that bugs and patches have more chance of being included in a new
Python version if the submitter is subscribed to python-dev and also
announces the bugs/patches there?

Partly that but more that the impending release of 2.3.4 was announced
on python-dev, which gave people an opportunity to lobby for specific
patches to get in.

 

[beliavsky]

Thanks to the Python developers for their continuing work.

I wonder why the Linux installation needs to be more tedious than the
Windows counterpart. The problem is of course not specific to Python.
There are many Linux distributions, running on different kernels, but
maybe binaries that have been tested on the "major" distributions like
Debian, Red Hat / Fedora, SUSE, and Mandrake could be created. Compare
the instructions:

WINDOWS
"Windows users should download the Windows installer,
Python-2.3.4c1.exe, run it and follow the friendly instructions on the
screen to complete the installation. Windows users may also be
interested in Mark Hammond's win32all, a collection of
Windows-specific extensions including COM support and Pythonwin, an
IDE built using Windows components.

LINUX
All others should download either Python-2.3.4c1.tgz or
Python-2.3.4c1.tar.bz2, the source archive. The tar.bz2 is
considerably smaller, so get that one if your system has the
appropriate tools to deal with it. Unpack it with "tar -zxvf
Python-2.3.4c1.tgz" (or "bzcat Python-2.3.4c1.tar.bz2 | tar -xf -").
Change to the Python-2.3.4c1 directory and run the "./configure",
"make", "make install" commands to compile and install Python. The
source archive is also suitable for Windows users who feel the need to
build their own version."

 

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

I wonder why the Linux installation needs to be more tedious than the
Windows counterpart. The problem is of course not specific to Python.
There are many Linux distributions, running on different kernels, but
maybe binaries that have been tested on the "major" distributions like
Debian, Red Hat / Fedora, SUSE, and Mandrake could be created.

Volunteers are welcome.

Martin

 

[Erik Max Francis]

Thanks to the Python developers for their continuing work.

I wonder why the Linux installation needs to be more tedious than the
Windows counterpart. The problem is of course not specific to Python.
There are many Linux distributions, running on different kernels, but
maybe binaries that have been tested on the "major" distributions like
Debian, Red Hat / Fedora, SUSE, and Mandrake could be created.

Why do you think the standard and near-universal ./configure && make &&
make install is tedious?

 

[Anthony Baxter]

I wonder why the Linux installation needs to be more tedious than the
Windows counterpart. The problem is of course not specific to Python.
There are many Linux distributions, running on different kernels, but
maybe binaries that have been tested on the "major" distributions like
Debian, Red Hat / Fedora, SUSE, and Mandrake could be created. Compare
the instructions:

Please note that we usually do supply RPMs for released versions of
Python. This takes work, though, and it's not generally done for these
interim releases. In the case of a release candidate for a bug fix
release, we're talking about a lifetime of about a week - hardly worth
doing the work for that little a time. I certainly anticipate that RPMs
will be available for 2.3.4 (and thanks again go to Sean R. for doing
the work to make this happen).

As to why we provide an installer on Windows by default - most windows
users do not have access to a compiler. Most Linux and Unix users do.

As far as providing packages in other formats - well, this is an
open source effort. Unless someone steps forward and offers the
packaging work, it won't get done. Aside from anything else, I
certainly don't have the tools needed to make packages for Debian,
Gentoo, or whatever. (And please, I do not want to hear anyone
telling me that "obviously I should be running Debian/Gentoo/
some other distribution" -- I'm happy enough with the software
I'm running.)

Note also that most distributors of packaged Linux provide packaged
versions of Python in their distributions. One of my goals with the
way I do maintenance releases is to make them as simple and as safe
an upgrade as possible - this then hopefully means that the vendors
will update their packaged Python sooner rather than later.

hope this information is helpful,
Anthony

 

[Irmen de Jong]

Not at this point, sorry. It's generally assumed that people who care
about the progress of release schedules are subscribed to python-dev;
perhaps that assumption should be challenged.

Pardon my ignorance, but why is it that currently on python-dev there
are talks about including new modules into the standard lib for 2.4
(such as cookielib), while relatively trivial patches to existing modules
are no longer taken into account for 2.4?

--Irmen

 

[Aahz]

Pardon my ignorance, but why is it that currently on python-dev there
are talks about including new modules into the standard lib for 2.4
(such as cookielib), while relatively trivial patches to existing modules
are no longer taken into account for 2.4?

2.4 has plenty of time for patches to get accepted. There will be at
least a month after the first published alpha before a release candidate
gets created. I'm confused now because this thread has been about
2.3.4, which is a relatively low-effort bugfix release.

 

[Irmen de Jong]

2.4 has plenty of time for patches to get accepted. There will be at
least a month after the first published alpha before a release candidate
gets created. I'm confused now because this thread has been about
2.3.4, which is a relatively low-effort bugfix release.

You're right ofcourse. I mixed things up -- please ignore what I said
about 2.4. I'll think twice before posting about this again

-Irmen