[Python-Dev] test_minidom crash

Tim Peters tim.one@home.com
Sat, 24 Mar 2001 15:49:46 -0500


[Moshe]
> ...
> I just went through the core grepping for '$Revision' and it seems
> this is the only place this happens -- all the other places either put
> the default version (RCS cruft and all), or are smart about handling it.

Hmm.  Unless it's in a *comment*, I expect most uses are dubious.  Clear
example, from the new Lib/unittest.py:

__version__ = "$Revision: 1.2 $"[11:-2]

Presumably that's yielding an empty string under the new tarball release.

One of a dozen fuzzy examples, from pickle.py:

__version__ = "$Revision: 1.46 $"       # Code version

The module makes no other use of this, and since it's not in a comment I have
to presume that the author *intended* clients to access pickle.__version__
directly.  But, if so, they've been getting the $Revision business for years,
so changing the released format now could break users' code.

> ...
> However, whatever we do the Windows build and the UNIX build must be
> the same.

*Sounds* good <wink>.

> I think it should be possible to build the Windows version from the
> .tgz and that is what (IMHO) should happen, instead of Tim and Guido
> exporting from the CVS independantly. This would stop problems like the
> one Tim and I had this (my time) morning.

Ya, sounds good too.  A few things against it:  The serialization would add
hours to the release process, in part because I get a lot of testing done
now, on the Python I install *from* the Windows installer I build, while the
other guys are finishing the .tgz business (note that Guido doesn't similarly
run tests on a Python built from the tarball, else he would have caught this
problem before you!).

Also in part because the Windows installer is not a simple packaging of the
source tree:  the Windows version also ships with pre-compiled components for
Tcl/Tk, zlib, bsddb and pyexpat.  The source for that stuff doesn't come in
the tarball; it has to be sprinkled "by hand" into the source tree.

The last gets back to Guido's point, which is also a good one:  if the
Windows release gets built from a tree I've used for the very first time a
couple hours before the release, the higher the odds that a process screwup
gets overlooked.

To date, there have been no "process bugs" in the Windows build process, and
I'd be loathe to give that up.  Building from the tree I use every day is ...
reassuring.

At heart, I don't much like the idea of using source revision numbers as code
version numbers anyway -- "New and Improved!  Version 1.73 stripped a
trailing space from line 239!" <wink>.

more-info-than-anyone-needs-to-know-ly y'rs  - tim