RELEASED Python 2.3.1

[Anthony Baxter]

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

Python 2.3.1 is a pure bug fix release of Python 2.3, released in late
July. A number of obscure crash-causing bugs have been fixed, various
memory leaks have been squished, but no new features have been added to
the language or to the library.

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

http://www.python.org/2.3.1

Highlights of this new release include:

- Bugfixes

- The Windows installer now ships with documentation in searchable
htmlhelp format, rather than individual HTML files.

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

This release was the work of a number of dedicated python-dev folks who
took the time to apply bugfixes back to the 2.3 code. The community owes
them many thanks for this work.

Enjoy the new release,
Anthony

Anthony Baxter
(e-mail address removed)
Python 2.3.1 Release Manager
(on behalf of the entire python-dev team)

 

[Dave Brueck]

I agree that a separate Windows run-only distribution (including .pyc
instead of .py files)

FWIW, shipping the .py and _not_ the .pyc has one advantage in that the .py's
tend to compress better. Combined with zipimporters in 2.3 this can result in
a nice, small run-time.

would be a good idea. But someone has to
volunteer the time or money to make it happen. The current release
procedure is still being refined and documented by the current
volunteers.

I've been working on a simplistic implementation of such a run-time for my own
projects. It's functional but very experimental (read: does what I need and
not much else) and not well-documented or anything, but if anybody wants to
play with what I've done so far just drop me a line. It's nice and small:

19,530 ctypes.zip
18,944 pycb.exe
1,908 pycbcom.tlb
19,456 pycbw.exe
445,952 python23.dll
749,092 python23.zip
3,072 w9xpopen.exe
20,480 _ctypes.pyd

(1.2 MB total - has _socket, select, _winreg, etc built in to the main dll)

It registers itself as an ActiveX control so that from Internet Explorer you
can have a web page query to see if the run-time has been installed (so that,
e.g., you can have the user download the app+runtime or just the app).

Small download size is a primary goal, with a close second being very little
differentiation between the dev (.py) and release (.exe) environments (which
has bitten me many times in the past). Thus I don't run python.exe any more
at all for projects that will end up being distributed this way.

The library also registers the .pycb extension with Windows (pycb = "Python
code bundle") so that you can distribute your code in a small app.pycb file
that, from the user's perspective, is an "executable". For example, for a
personal project I just completed the entire distribution consisted of:

venster.pycb (82k)
main.pycb (15k)

Under 100KB is not bad for a GUI app!

The .pycb format is basically ZIP + AES encryption, and pycb uses the new
import hooks in 2.3 to handle it. The encryption is just to keep honest
people out; anybody with the right combination of smart and bored could
figure out how to circumvent it.

-Dave

 

[Peter Hansen]

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

The highlights mention the existence of a new API PyThreadState_SetAsyncEnc,
which is "deliberately accessible only from C", that can interrupt a thread
by sending it an exception.

I can't find an online discussion of this, so I'm asking here. Why was this
made accessible only from C? Is it dangerous? Experimental? Someone feels
it will be used inappropriately if too readily available at the Python level?

Presumably somebody will come up with a little extension module or other
technique for calling this which will let anyone use it at will, so I'm unclear
on why it should be made inaccessible from Python.

-Peter

 

[Dave Brueck]

I've been working on a simplistic implementation of such a run-time
for my own projects. [snip]
445,952 python23.dll

Interesting.

Is the python23.dll compressed,or did you leave features out?

I started to leave out stuff like imageop, audioop, etc - stuff I never use,
but I believe in the end I decided not to bother since it wouldn't amount to
a big difference, so IIRC that's a normal python23.dll (with "minimize size"
compiler optimizations turned on) + select + _socket + _sre + pyexpat + zlib
+ _winreg + aes then run through UPX.

-Dave

 

[Cousin Stanley]

| ...
| The Windows installer now ships with documentation
| in searchable htmlhelp format, rather than individual
| HTML files.
| ...

Is the htmlhelp format optional for Windows ???

Sometimes I like to edit the individual HTML docs ....

 

[John J. Lee]

| ...
| The Windows installer now ships with documentation
| in searchable htmlhelp format, rather than individual
| HTML files.
| ...

Is the htmlhelp format optional for Windows ???

Sometimes I like to edit the individual HTML docs ....

You can download the HTML docs separately, or decompile the .chm back
to HTML. See recent threads about this.


John

 

[Thomas Heller]

| ...
| The Windows installer now ships with documentation
| in searchable htmlhelp format, rather than individual
| HTML files.
| ...

Is the htmlhelp format optional for Windows ???

Sometimes I like to edit the individual HTML docs ....

There's a checkbox which you can uncheck to disable installing the
htmlhelp file. Then you can download the HTML archive and install it
manually.

Thomas

 

[Shu-Hsien Sheu]

Hi,

Sometimes, it is find of nice using:
print >> my_file_object, my_variabels
than using the standard f.write.
However, it cannot be done with pprint.pprint.
I understand that i can do it by redirecting the sys.stdout, but isn't
it nice if I can do something like pprint.pprint >> my_file_object,
my_dictionary?

BTW, the syntax
print >> my_file_object, my_variables
seems a bit awkward to me.
Isn't it better if we can simply use:
print *whatever_this_is >> my _file_object
just like the way we do in unix shell?

-shuhsien

 

[vincent wehren]

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

Than why does the documentation (at least the Windows CHM-one) repeat the
claim:

"Release 2.4a0, documentation updated on 23 September 2003." on each page!



Vincent Wehren

 

[Raymond Hettinger]

| The Windows installer now ships with documentation
| in searchable htmlhelp format, rather than individual
| HTML files.
| ...

Is the htmlhelp format optional for Windows ???

Sometimes I like to edit the individual HTML docs ....

Yes, you can still download the individual HTML files at:
http://www.python.org/ftp/python/doc/2.3.1/


Raymond Hettinger

 

[Peter Hansen]

Sometimes, it is find of nice using:
print >> my_file_object, my_variabels
than using the standard f.write.
However, it cannot be done with pprint.pprint.

I suspect you are looking for either the second argument to pprint(),
or pprint.pformat() instead.

pprint.pprint(my_variables, my_file_object)

or

print >>my_file_object, pprint.pformat(my_variables)

-Peter

 

[Skip Montanaro]

Shu-Hsien> Sometimes, it is find of nice using: print >> my_file_object,
Shu-Hsien> my_variabels than using the standard f.write. However, it
Shu-Hsien> cannot be done with pprint.pprint.

Actually, yes you can. Pprint.pprint() takes an optional second argument
which specifies the stream to write to. It defaults to sys.stdout.

Skip

 

[Chris Liechti]

The highlights mention the existence of a new API
PyThreadState_SetAsyncEnc, which is "deliberately accessible only from
C", that can interrupt a thread by sending it an exception.

I can't find an online discussion of this, so I'm asking here. Why
was this made accessible only from C? Is it dangerous? Experimental?
Someone feels it will be used inappropriately if too readily
available at the Python level?

martellibot has something about it:
http://www.strakt.com/docs/os03_threads_interrupt.pdf

Presumably somebody will come up with a little extension module or
other technique for calling this which will let anyone use it at will,
so I'm unclear on why it should be made inaccessible from Python.

why bother with c, just use ctypes to call the function ;-)

chris

 

[Peter Hansen]

why bother with c, just use ctypes to call the function ;-)

How would one do that? It would make for an easy way to experiment
with it, in the 0.001% of cases where a non-newbie one might want to
do such a thing. ;-)

Is this function available in a DLL somewhere? I can't find even
a single reference to that name anywhere in the Python23 directory
tree on Win32 after a fresh install.

-Peter

 

[Tim Hochberg]

How would one do that? It would make for an easy way to experiment
with it, in the 0.001% of cases where a non-newbie one might want to
do such a thing. ;-)

Is this function available in a DLL somewhere? I can't find even
a single reference to that name anywhere in the Python23 directory
tree on Win32 after a fresh install.

It's here:

http://starship.python.net/crew/theller/ctypes/

-tim

 

[Peter Hansen]

Is this function available in a DLL somewhere? I can't find even
a single reference to that name anywhere in the Python23 directory
tree on Win32 after a fresh install.

Skip that question....of course, python23.dll goes into c:\windows\system
so it wasn't where I was searching...

I'd still be very interested in examples of use through ctypes (with
which I'm not yet familiar).

Alex' slides were interesting, but I think they might reflect a subtle
trend away from Python's traditional treatment of programmers as
consenting adults, with all the concern about newbies and the hints
that such a dangerous feature will be abused to no end.

The slides also suggest that there are almost no use cases whatsoever
for such a feature, though admitting there might, just barely, be enough
to merit adding it as a non-newbie C-only API which one has to jump
through hoops (or use ctypes to access.

I can think of several use cases right off the top of my head, one
of them being while running automated unit and acceptance tests,
to ensure that a test involving threads will complete (generally
with a failure in this case) even if the code is broken and the
thread cannot be terminated.

-Peter

 

[Peter Hansen]

It's here:

http://starship.python.net/crew/theller/ctypes/

Sorry, Tim, I meant the PyThreadState_SetAsyncEnc function, not
ctypes itself. See my other posting, where I report I found it...

-Peter

 

[Terry Reedy]

Than why does the documentation (at least the Windows CHM-one) repeat the
claim:
"Release 2.4a0, documentation updated on 23 September 2003." on each page!

Because of a glitch in the release process that wasn't noticed until
just after the release, and because it was not seen as serious enough
to withdraw until redone.

The main development line for Python *is* the future 2.4a0 release.
Some or most bug-fix only patches (including doc patches) were
backported to the 2.3 maintainance branch (of CVS repository) to make
this release. Somehow, one thing too many got backported ;-).

Terry J. Reedy

 

[Cousin Stanley]

| You can download the HTML docs separately,
| or decompile the .chm back to HTML.
| See recent threads about this.

John ....

Thanks for the reply ....

It's nice to know there are options ....

 

[Cousin Stanley]

| There's a checkbox which you can uncheck
| to disable installing the htmlhelp file.
|
| Then you can download the HTML archive
| and install it manually.

Thomas ....

Thanks for the reply ....

It's good to know that an alternative
for the individual HTML doc files will remain ....

Would it be feasible to eliminate the Python Docs
from the standard distribution and always download
separately if desired ????

This would eliminate downloading the docs twice
if the user wants the separate doc files and provide
a leaner download for non-programming Python users
that will never develop anything in Python themselves
but who want a run-time environment only ....