By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,095 Members | 1,658 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,095 IT Pros & Developers. It's quick & easy.

RELEASED Python 2.3.4, release candidate 1

P: n/a
-----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
an*****@python.org
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+iQ cc581wbQCgh1Ah
f/Ci2omZVG7p63xY9cfZiSw=
=e3Rv
-----END PGP SIGNATURE-----

Jul 18 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Anthony Baxter wrote:
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...70&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.
Jul 18 '05 #2

P: n/a
In article <40*********************@news.xs4all.nl>,
Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> wrote:
Anthony Baxter wrote:

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...70&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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
Jul 18 '05 #3

P: n/a
Aahz wrote:
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.


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?
Jul 18 '05 #4

P: n/a
Irmen de Jong wrote:
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

Jul 18 '05 #5

P: n/a
Irmen de Jong wrote:
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

Jul 18 '05 #6

P: n/a
Martin v. Lwis wrote:
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.
Jul 18 '05 #7

P: n/a
Irmen de Jong wrote:
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

Jul 18 '05 #8

P: n/a
In article <40*********************@news.xs4all.nl>,
Irmen de Jong <irmen@-nospam-remove-this-xs4all.nl> wrote:
Aahz wrote:
Irmen deleted his own attribution:

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.


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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
Jul 18 '05 #9

P: n/a
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."
Jul 18 '05 #10

P: n/a
be*******@aol.com wrote:
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

Jul 18 '05 #11

P: n/a
be*******@aol.com wrote:
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?

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ This moment is / Mine
-- Chante Moore
Jul 18 '05 #12

P: n/a
be*******@aol.com wrote:
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
--
Anthony Baxter <an*****@interlink.com.au>
It's never too late to have a happy childhood.

Jul 18 '05 #13

P: n/a
Aahz wrote:
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.


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
Jul 18 '05 #14

P: n/a
In article <40***********************@news.xs4all.nl>,
Irmen de Jong <irmen@-nospam-remove-this-xs4all.nl> wrote:
Aahz wrote:
Irmen deleted his own attribution:

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.


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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
Jul 18 '05 #15

P: n/a
Aahz wrote:
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
Jul 18 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.