Eliminating upgrade risk

John Roth johnroth at ameritech.net
Wed Jul 25 20:51:30 CEST 2001

After enduring the PEP 238 threads for far too long, as well as other
threads, I've come to the conclusion that Python is simply too unstable
for real use.

Now, I've got a slightly different background here. Much of my
professional life was in IBM mainframe shops, where installing a new
version of the operating system, major utilities and language processors
was essentially **guaranteed** not to break running applications. I
can remember numerous upgrades where I had to do absolutely
nothing on the applications side.  I also have been in shops where
programs written in the mid '70s are still running the same executable!

You can't always guarantee 100% compatibility while providing new
functionality, but you can certainly provide the framework.

The root of most of the upgrade problems (PEP 238 being the exception)
is that keywords come from the same namespace as other names. Most
languages have this problem, and most languages don't solve it, either.

Therefore: the Proposal (ta da!)

Add a new statement named "required". This statement, if present, must
occur before any other statement in a module except comments and
docstrings. If it is not present, it will not be considered a reserved word
in the remainder of the module. If it is, it will be so considered.

It also won't be considered as a new statement if it's immediately followed
by an "=" sign.

The rest of the statement is simply a list of keyword, value pairs, where
keywords can be added to from release to release with impunity. The syntax
for the pairs could be keyword = value, or keyword: value, with commas
between the pairs. I have no real opinion on the matter, other than that it
allow for essentially unlimited extensibility.

The initial set of keywords could be:

earliest-release: <release number>
latest-release: <release number>
tested-release: <release number>

earliest-release means that the module requires at least that level of the
system. Python releases that recognize the requires statement will refuse to
run (or import) the module if they are at an earlier level.

latest-release means that the module is known not to work on later releases
of Python. Python releases later than this level will compile and run the
module using the prior release's semantics.

tested-release simply means that it was working on that release, and may not
work on later releases. This is documentation only; the Python interpreter
automatically supply messages when it is running under a command line, but
not if it is running under a GUI.

A second part of this would be an optional file named "__requires__.py" in
directory that contained python source or executables. This would contain
requires statements for (some of) the various modules in the directory that
supply or override the requires statement in the module.

Hopefully, this is going to provide more food for thought than fuel for the

John Roth

More information about the Python-list mailing list