RELEASED Python 2.3.4, release candidate 1

**Irmen de Jong** · Jul 18 '05, 10:52 AM

Re: RELEASED Python 2.3.4, release candidate 1

Anthony Baxter wrote:[color=blue]
> 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).[/color]

Cool! Thanks.

I've got a question though, I've submitted a patch for a bug in
SimpleHTTPServe r.py in december last year;

Page not found - SourceForge.net

http://sourceforge.net/tracker/?func=detail&aid=839496&group_id=5470&atid=305470

SimpleHTTPServe r 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** · Jul 18 '05, 10:52 AM

Re: RELEASED Python 2.3.4, release candidate 1

In article <40a39511$0$560 $e4fe514c@news. xs4all.nl>,
Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> wrote:[color=blue]
>Anthony Baxter wrote:[color=green]
>>
>> 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).[/color]
>
>Cool! Thanks.
>
>I've got a question though, I've submitted a patch for a bug in
>SimpleHTTPServ er.py in december last year;
>http://sourceforge.net/tracker/?func...70&atid=305470
>
>SimpleHTTPServ er 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?[/color]

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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!

**Irmen de Jong** · Jul 18 '05, 10:52 AM

Re: RELEASED Python 2.3.4, release candidate 1

Aahz wrote:
[color=blue][color=green]
>>SimpleHTTPSer ver 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?[/color]
>
>
> 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.[/color]

That's unfortunate, I reported it even before 2.3.3 was released.
Doesn't anybody use SimpleHTTPServe r 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?

**Martin v. Löwis** · Jul 18 '05, 10:53 AM

Re: RELEASED Python 2.3.4, release candidate 1

Irmen de Jong wrote:[color=blue]
> 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?[/color]

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

**Martin v. Löwis** · Jul 18 '05, 10:53 AM

Re: RELEASED Python 2.3.4, release candidate 1

Irmen de Jong wrote:[color=blue]
> 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?[/color]

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** · Jul 18 '05, 10:53 AM

Re: RELEASED Python 2.3.4, release candidate 1

Martin v. Löwis wrote:
[color=blue]
> 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.[/color]

Fair enough.
[color=blue]
> If any submitter
> of a patch would review 10 other patches, there would be no backlog.[/color]

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.

**Martin v. Löwis** · Jul 18 '05, 10:53 AM

Re: RELEASED Python 2.3.4, release candidate 1

Irmen de Jong wrote:[color=blue]
> Would it be an idea to 'announce' this on the newsgroup, a certain
> period before releasing a new Python version?[/color]

I announce statements like this every year or so. Sometimes, this
causes a burst of help, but unfortunately, nothing sustainable.
[color=blue]
> "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?[/color]

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** · Jul 18 '05, 10:54 AM

Re: RELEASED Python 2.3.4, release candidate 1

In article <40a3b2f6$0$568 $e4fe514c@news. xs4all.nl>,
Irmen de Jong <irmen@-nospam-remove-this-xs4all.nl> wrote:[color=blue]
>Aahz wrote:[color=green]
>>Irmen deleted his own attribution:[color=darkred]
>>>
>>>SimpleHTTPSe rver 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?[/color]
>>
>> 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.[/color]
>
>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?[/color]

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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!

**beliavsky@aol.com** · Jul 18 '05, 10:55 AM

Re: RELEASED Python 2.3.4, release candidate 1

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

**Martin v. Löwis** · Jul 18 '05, 10:55 AM

Re: RELEASED Python 2.3.4, release candidate 1

beliavsky@aol.c om wrote:[color=blue]
> 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.[/color]

Volunteers are welcome.

Martin

**Erik Max Francis** · Jul 18 '05, 10:55 AM

Re: RELEASED Python 2.3.4, release candidate 1

beliavsky@aol.c om wrote:
[color=blue]
> 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.[/color]

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

--
__ Erik Max Francis && max@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

**Anthony Baxter** · Jul 18 '05, 10:56 AM

Re: RELEASED Python 2.3.4, release candidate 1

beliavsky@aol.c om wrote:[color=blue]
> 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:[/color]

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 <anthony@interl ink.com.au>
It's never too late to have a happy childhood.

**Irmen de Jong** · Jul 18 '05, 10:56 AM

Re: RELEASED Python 2.3.4, release candidate 1

Aahz wrote:
[color=blue][color=green]
>>SimpleHTTPSer ver 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?[/color]
>
> 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.[/color]

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** · Jul 18 '05, 10:56 AM

Re: RELEASED Python 2.3.4, release candidate 1

In article <40a60334$0$651 24$e4fe514c@new s.xs4all.nl>,
Irmen de Jong <irmen@-nospam-remove-this-xs4all.nl> wrote:[color=blue]
>Aahz wrote:[color=green]
>>Irmen deleted his own attribution:[color=darkred]
>>>
>>>SimpleHTTPSe rver 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?[/color]
>>
>> 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.[/color]
>
>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?[/color]

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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!

RELEASED Python 2.3.4, release candidate 1

RELEASED Python 2.3.4, release candidate 1

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment