Python 1.4 And Beyond

Python 1.4

Python 1.4 will be released (hopefully) soon after the workshop. Here's a (rather haphazard) overview of what's new. Many small bugs have also been fixed (and new ones introduced :-) -- these are generally not listed.

Many changes (and even more bug fixes) have been contributed by Python users. I can't thank them all individually any more, but I couldn't have done it wouthout them!

Most Embarrassing Bug Fixed

• The #define PYTHON_API_VERSION wasn't changed between Python 1.2 and 1.3, even though the APIs were actually incompatible.

Most Embarrassing Memory Leak Fixed

• Loading a module's code object from the .pyc file would leak all variable names.

Core Language

The following changes were proposed by the Matrix SIG.

• The ** operator is now official as an alternate spelling for to-the-power. The pow() built-in function will continue to be supported; it is still the only way to invoke the ternary power operator: pow(x, y, z) equals (x**y)%z, but is calculated more efficiently.
• Complex numbers are now officially part of the language (though it only takes one #define to take them out again). There's a notation for imaginary literals: 1j**2 equals -1.0, and there's a complex math module (cmath) which supports the same set of functions as the math module.

New In C Modules

New C Module

• There will most likely be a new module "operator" defining built-in functions __add__, __sub__ and so on, so you can write map(operator.__add__, list) instead of map(lambda x, y: x+y, list). The advantage is that operator.__add__ is implemented in C (using the abstract object interface), so execution will be a lot faster.

Changes In Existing C Modules

• The fcntl module now implements the flock() system call.
• The bugs in the bsddb module have been eradicated. (Unfortunately the bugs with simultaneous access in the BSD DB library itself haven't been fixed -- the BSD DB people are working on a version 2.0 though.)
• The 'new' module now has a function to create classes.
• The posix module (which you should always invoke through its "os" alias!) has new functions mkfifo(), ftruncate(), and remove() (== unlink()). The second argument to mkdir() is now optional.

New In Python Modules

New Modules

• New module ArrayIO.py, similar to StringIO.py, but uses a mutable character array to hold the data. This is faster when writing (but slower when reading).
• New module mimify.py, to encode or decode MIME messages.
• New script Tools/scripts/mailerdaemon.py, for parsing mailer-daemon error messages.

Changes In Existing Modules

• Several modules have been updated to avoid using eval() where a simple atoi() or atof() would do. This includes the pickle.py module, where it improves performance as well.
• Several modules have been updated to open files in binary mode ('rb' or 'wb') for Mac and PC portability.
• The getdir() function in the tempfile.py module is more robust in case /usr/tmp or /tmp is unwritable.
• translate() added to string.py (it was already in strop.c).
• The interface to RHook in rexec.py, which was impossible to use because of a recursive reference, has been changed. There is now also support for loading trusted modules from shared libraries.
• The UserList.py module now supports the operators + and *.
• Function split() in module regsub.py can now optionally return delimiters.
• Most likely, a new function capitalize() will be added to string.py and strop.py, and capitalize_words() will be added to regsub.

Changes In Web/Internet/Mail Modules

• The mhlib.py module has several enhancements, such as Folder.parsesequence(), which parses a sequence argument as accepted by most MH shell tools (e.g. "last:10"), and MH.setcontext(), to set the name of the current folder.
• The mailbox.py module defines a new class MHMailbox.
• New function defrag() in module urlparse.py, to remove a #fragment identifier from a URL.
• Proxy handling added to module urllib.py.
• Module sgmllib.py has been rewritten (again), for better SGML conformance. This affects htmllib.py through inheritance.
• The formatter.py module has been updated to provide better handling of line and paragraph breaks. There's also a new class, NullWriter.
• The ftplib.py module has been updated to support PASV mode.
• The cgi.py module has been rewritten to provide a more flexible interface and to support file upload from forms. It now also has a sizeable __doc__ string.
• Module rfc822.py now stores headers in a dictionary, so getheader() is much more efficient.

Source And Build Issues

Source Organization

• The Grand Renaming (e.g. newintobject() -> PyInt_FromLong()) still isn't done. :-( Only a few more files have been converted. Good news: more functions have been assigned new names (e.g. getpythonpath() -> Py_GetPathh()). The MD5 and regular expression support functions now have a _Py_ prefix so the won't clash with similar symbols in some vendors' C libraries.
• The "Python.h" header file now includes more standard headers.
• The "NDEBUG" preprocessor define is no longer used. By default, Python is built without debugging (this was always the case, but there was some contention between NDEBUG and DEBUG).
• Defining "DEBUG" turns on heavy duty reference count debugging, as well as a number of other debugging features. These features can also be enabled individually. Unlike Python 1.3, using these has actually been tested and will not result in compilation errors.

Build And Installation Process

• At long last, "make install" will install everything, not just the python binary. It will also create the required directories if they don't already exist (even bin, lib, include, man etc.). There are individual targets if you want to do a selective installation.
• Shared libraries, when created, will be installed automatically as well.
• Hopefully, installing the library will also regenerate the platform dependent *.py files in the platform subdirectory of the library.

Shared Libraries

• There will be support for shared libraries on most platforms that support them (including Windows and Mac PPC -- Mac 68K is dubious, depending on CFM68K support in the CodeWarrior 9 compiler).
• New platforms supported include NetBSD/FreeBSD, and 16-bit Windows 3.1.

Threads

• There will be better thread support. Posix threads will be supported on all Unix platforms that have them (this includes Solaris 2.5).
• The Mac and Windows ports still don't have working threads, but we hope to be working towards these -- these operating systems now support threads so there's no reason why Python shouldn't.

Tkinter

• The tkinter C module has been renamed to _tkinter.c. This solves problems on case insensitive file systems (Mac, PC) and prevents confusion for ni.py (packages).
• Python 1.4 will support Tk 4.1 as well as Tk 4.0, so you have a choice but not the requirement to upgrade. Tk 3.6 and below are no longer supported (where have you been!).
• Tkinter is now supported on the Windows and Mac platforms.
• Tkinter.py has been tweaked for better performance; some functions have been reimplemented to C.
• Many new Tk commands have been added to Tkinter, including a class for the Grid geometry manager (new in Tk 4.1).
• The "official" names for widget commands are now supported throughout -- if you see " tag configure ..." in the man page, you will be able to call widget.tag_configure(...). The old shorthands like tag_config() are still usable but considered obsolete.
• The FileDialog.py module has been much enhanced, and a new SimpleDialog.py module replaces the the now obsolete Dialog.py module.
• While this version still supports the old dictionary form of passing options to widget constructors and configure methods, this form is now officially obsolete. The next release will no longer support this. Compare for yourself:
  Button(master, text="Hello world", command=show_it)
  looks a lot better than
  Button(master, {'text': "Hello world", 'command': show_it}).

Ports

The Mac and Windows ports are now being maintained and distributed independently from the core distribution. This is not because those ports are less important (far from it!), but because of a reality check. New versions of these ports are released at a much higher frequency than the core distribution. It makes sense not to have an out-of-date port as part of the core distribution, since this would only confuse potential users of the port.

Moreover, the ports for those platforms are much more useful when distributed in binary form anyway. Unlike in the Unix world, the majority of potential Python users on Mac or Windows does not have a compiler installed.

This doesn't mean that the Mac or Windows ports have less priority. In fact, I've worked hard to integrate the necessary changes so that those ports only need to add files -- all the required changes to the core sources necessary for those ports are now distributed as part of the 1.4 core distribution. Perhaps Makefiles and config.[ch] files for the various DOS and Windows compilers will be distributed, so it will be possible to build at least a minimal system.

The PC version will now compile with three different compiler systems: Borland, Microsoft and Watcom. Both Jim Ahlstrom's WPY and Mark Hammond's PythonWin will be able to use the core sources unchanged. There's a special hack to support importing modules whose name is longer than 8 characters on a FAT filesystem (if the directory name is "dos_8x3", the module name is truncated before doing the lookup).

There's talk of a port to the GEOS operating system. This x86 based OO OS is in dire need of a scripting language. I've been approached by a company which is interested in developing and marketing such a port as part of a GEOS release aimed at the ever-increasing "obsolete PC" market. This consists of machines too small to run Windows '95, but still good enough for their owners -- Microsoft does not support those users any more.

Late-breaking news: Python has now been ported to the Apple IIgs under the Gnome RT OS!!!

Python 1.5

In the light of the next section, it's not clear that there ever will be a Python 1.5 release. It will certainly contain mostly minor updates.

Python 2.0

I'm working already on what will become Python 2.0. It will most likely be distributed in beta form first, by the end of 1996. Some highlights of expected features:

• Grand Renaming completed (at long last -- sigh). Source files will most likely be renamed as well.
• Many arbitrary restrictions on argument types to built-in functions and operations will be lifted, using the abstract object interface. In particular, many more functions/operations will support an arbitrary mapping or sequence instead of just a dictionary, tuple or list.
• The virtual machine will be rewritten to eliminate the C stack (in most cases, anyway). This will makes it possible to implement migratory Python prorams, as well as portable coroutines. Together with an asynchronous I/O library, this could be used to implement portable threads. I hope that this reimplementation will pave the way to a faster implementation as well.