RELEASED Python 2.4.2 (final)

[Anthony Baxter]

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

Python 2.4.2 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 more than 60 bugs squished in this release.

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

http://www.python.org/2.4.2

Highlights of this new release include:

- Bug fixes. According to the release notes, more than 60 have been
fixed, including bugs that prevented Python from working properly
on 64 bit HP/UX and AIX systems.

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

http://www.python.org/2.4/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.4.1 (GNU/Linux)

iD8DBQBDOpApDt3F8mpFyBYRAgdxAKC85ssW10hOce4JzBqEyG TqmBuQlwCbBfqX
iF7Qb1CSr6xO3FWwawPiPFM=
=aKTB
-----END PGP SIGNATURE-----

[Michael Ströder]

Anthony Baxter wrote:

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

Does that differ from 2.4.2c1? On Monday I noticed a crash in the test
suite on a box running Solaris 8. It seems I can build Python 2.4.1 and
run make test there without problems.

But being busy during the last days I did not have the time to track it
down and report a bug... :-/

Ciao, Michael.

[Terry Reedy]

"Michael Ströder" <mi*****@stroeder.com> wrote in message
news:5h************@nb2.stroeder.com...

Does that differ from 2.4.2c1? On Monday I noticed a crash in the test
suite on a box running Solaris 8. It seems I can build Python 2.4.1 and
run make test there without problems.
There were are few additional fixes that Anthony thought were simple enough
to release after whatever 'in-house' testing but without a c2 release.
But being busy during the last days I did not have the time to track it
down and report a bug... :-/

Apparently, no one else reported much of anythong either...
If necessary, 2.4.3 will come sooner than currently planned.

Terry J. Reedy

[Martin v. Löwis]

Michael Ströder wrote:

Does that differ from 2.4.2c1? On Monday I noticed a crash in the test
suite on a box running Solaris 8. It seems I can build Python 2.4.1 and
run make test there without problems.

There is also a chance that you found a compiler bug. So reporting the
compiler you used would be essential.

Regards,
Martin

[Bugs]

I downloaded the 2.4.2 Windows Binary Installer from python.org but when
I try to run python.exe I get the following in the console:
--------------------
ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

--------------------
It says ActivePython 2.4.1 but I downloaded the 2.4.2 binary installer
from python.org and the python.exe executable I'm running is timestamped
9/28/2005 12:41PM... Any ideas what I'm doing wrong?

Thanks!

[Trent Mick]

[Bugs wrote]

I downloaded the 2.4.2 Windows Binary Installer from python.org but when
I try to run python.exe I get the following in the console:
--------------------
ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

>>>

--------------------
It says ActivePython 2.4.1 but I downloaded the 2.4.2 binary installer
from python.org and the python.exe executable I'm running is timestamped
9/28/2005 12:41PM... Any ideas what I'm doing wrong?

It is possible that the python.org installer didn't overwrite the
"python24.dll" in the system directory (C:\WINDOWS\system32). Try doing
this:

- manually delete C:\WINDOWS\system32\python24.dll
- run the "repair" functionality of the python.org installer (you can
either do this from "Start | Settings | Control Panel | Add/Remove
Programs" or by just running the .msi file again

Then try running python again.

Trent
--
Trent Mick
Tr****@ActiveState.com

[Bugs]

Thanks Trent, you called it, it was an errant python24.dll left over
from an old ActiveState installation.

Trent Mick wrote:
[snip]

It is possible that the python.org installer didn't overwrite the
"python24.dll" in the system directory (C:\WINDOWS\system32). Try doing
this:

[snip]

[Martin v. Löwis]

Trent Mick wrote:

It is possible that the python.org installer didn't overwrite the
"python24.dll" in the system directory (C:\WINDOWS\system32). Try doing
this:

Even though this is apparently what happened, I'm puzzled as to why it
happened: shouldn't the version number of python24.dll in the pydotorg
installer be higher than the one in the ActivePython installer, and
shouldn't then Windows Installer overwrite the DLL?

The version in the pydotorg installer is 2.4.2150.1012.

Regards,
Martin

[Fuzzyman]

On Thu, 29 Sep 2005 17:53:47 -0700, Bugs <do**@spam.me> wrote:

I downloaded the 2.4.2 Windows Binary Installer from python.org but when
I try to run python.exe I get the following in the console:
--------------------
ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

--------------------
It says ActivePython 2.4.1 but I downloaded the 2.4.2 binary installer
from python.org and the python.exe executable I'm running is timestamped
9/28/2005 12:41PM... Any ideas what I'm doing wrong?

I had problems updating from activestate 2.4 to activestate 2.4.1

I think it was caused by not uninstalling the original. This does mean
that even a *minor* version upgrade is a PITA. To do it cleanly all
extension modules have to be uninstalled and re-installed.

*sigh*

Fuzzyman
http://www.voidspace.org.uk/python
Thanks!

[Michael Ströder]

Martin v. Löwis wrote:

Michael Ströder wrote:

Does that differ from 2.4.2c1? On Monday I noticed a crash in the test
suite on a box running Solaris 8. It seems I can build Python 2.4.1 and
run make test there without problems.

There is also a chance that you found a compiler bug. So reporting the
compiler you used would be essential.

It's gcc 3.0 installed by a Solaris 8 (probably outdated) package from
http://www.sunfreeware.com

I can dig further into on Tuesday. It's not my box.

Ciao, Michael.

[Steve Holden]

Fuzzyman wrote:

On Thu, 29 Sep 2005 17:53:47 -0700, Bugs <do**@spam.me> wrote:

I downloaded the 2.4.2 Windows Binary Installer from python.org but when
I try to run python.exe I get the following in the console:
--------------------
ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

--------------------
It says ActivePython 2.4.1 but I downloaded the 2.4.2 binary installer

from python.org and the python.exe executable I'm running is timestamped

9/28/2005 12:41PM... Any ideas what I'm doing wrong?

I had problems updating from activestate 2.4 to activestate 2.4.1

I think it was caused by not uninstalling the original. This does mean
that even a *minor* version upgrade is a PITA. To do it cleanly all
extension modules have to be uninstalled and re-installed.

*sigh*

Not necessarily so. You should find the uninstall leaves all your local
additions in place in site-packages, immediately available when a new
minor version is installed.

Until 2.5, of course, *then* you'll need to reinstall.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Peter Hansen]

Martin v. Löwis wrote:

Trent Mick wrote:

It is possible that the python.org installer didn't overwrite the
"python24.dll" in the system directory (C:\WINDOWS\system32). Try doing
this:

Even though this is apparently what happened, I'm puzzled as to why it
happened: shouldn't the version number of python24.dll in the pydotorg
installer be higher than the one in the ActivePython installer, and
shouldn't then Windows Installer overwrite the DLL?

Couldn't it also happen if the first time someone did an "admin" install
which (I believe) puts the DLLs in the system folder, and the next time
did just a non-admin install which doesn't do that? (Or am I
misunderstanding the conditions under which c:\windows\system32 has
files written to it?)

-Peter

[Trent Mick]

[Peter Hansen wrote]

Couldn't it also happen if the first time someone did an "admin" install
which (I believe) puts the DLLs in the system folder, and the next time
did just a non-admin install which doesn't do that? (Or am I
misunderstanding the conditions under which c:\windows\system32 has
files written to it?)

I suppose that is possible. Martin, does python-2.4.2.msi install
python24.dll to the Python install dir for a "per-user" installation?

Note: I started this bug to track this and try to repro:
http://bugs.activestate.com/ActivePy...g.cgi?id=41083

Trent

--
Trent Mick
Tr****@ActiveState.com

[Trent Mick]

[Fuzzyman wrote]

I had problems updating from activestate 2.4 to activestate 2.4.1

I think it was caused by not uninstalling the original. This does mean
that even a *minor* version upgrade is a PITA. To do it cleanly all
extension modules have to be uninstalled and re-installed.

*sigh*

As Steve said, uninstalling ActivePython 2.4 will leave your extensions
alone and then installing ActivePython 2.4.1 will install in the same
proper places so that all your extensions should just work.

Trent

--
Trent Mick
Tr****@ActiveState.com

[Martin v. Löwis]

Trent Mick wrote:

I suppose that is possible. Martin, does python-2.4.2.msi install
python24.dll to the Python install dir for a "per-user" installation?

Yes, that is supported. It would be good if Bugs could confirm that
he only deleted the wrong python24.dll, with the proper one being
installed in a different place already. His explanation
"you called it, it was an errant python24.dll left over from an old
ActiveState installation." is too imprecise to be able to tell
whether the two python DLLs where in the same location (requiring
a repair step) or in different locations (likely then resulting from
one being per-machine, and the other per-user).

Bugs?

Regards,
Martin

[Bugs]

- I had an old ActiveState python24.dll in \windows\system32 which I
deleted. That must've been left over from a 2.4.1 ActiveState
installation which I had installed then uninstalled sometime ago.

- I then uninstalled Python 2.4.2 and re-installed it for "all" users.
After that everything seemed to work properly.
I'm not sure where the Python 2.4.2 installation put it's python24.dll?

Please let me know if you need additional details.

Thanks,
Bugs

Martin v. Löwis wrote:

Trent Mick wrote:

I suppose that is possible. Martin, does python-2.4.2.msi install
python24.dll to the Python install dir for a "per-user" installation?

Yes, that is supported. It would be good if Bugs could confirm that
he only deleted the wrong python24.dll, with the proper one being
installed in a different place already. His explanation
"you called it, it was an errant python24.dll left over from an old
ActiveState installation." is too imprecise to be able to tell
whether the two python DLLs where in the same location (requiring
a repair step) or in different locations (likely then resulting from
one being per-machine, and the other per-user).

Bugs?

Regards,
Martin

[Martin v. Löwis]

Bugs wrote:

- I had an old ActiveState python24.dll in \windows\system32 which I
deleted. That must've been left over from a 2.4.1 ActiveState
installation which I had installed then uninstalled sometime ago.

- I then uninstalled Python 2.4.2 and re-installed it for "all" users.
After that everything seemed to work properly.
That is somewhat mysterious...
I'm not sure where the Python 2.4.2 installation put it's python24.dll?
It depends on whether this is a "for all" installation, or a "just for
me" installation. In the "for all" installation, it goes to
\windows\system32. In the "just for me" installation, it goes to
c:\python24 (ie. the directory where python.exe is). The rationale
is that a non-admin user might not have enough permissions to
write to system32.
Please let me know if you need additional details.

It would be good if you could recall what mode the original 2.4.2
installation had. If it was "just for me", then you might have
installed the 2.4.2 version of python24.dll into the python directory.
Still, it is then puzzling why it would have used the version in
system32, as the application's (i.e. python.exe) directory should
be searched first.

For the record, please also report what operating system you
were using.

The other theory is that the 2.4.2 installer failed to overwrite
the ActivePython version. This should not have happened, though,
since the installer should have noticed that the 2.4.2 version
is newer than the 2.4.1 one (and indeed, in a test installation,
it did so correctly).

It is probably too late to recreate all details, so we should
just watch whether it happens again.

Regards,
Martin

[Maldini]

thanks

--
Junqing Zhou

MSN: zh**********@hotmail.com
Email: zh**********@126.com