[Python-Dev] test_minidom crash

[Guido van Rossum]

> People *will* be incorporating Python into their own CVS trees. FreeBSD
> does it with ports, and Debian are thinking of moving in this direction,
> and some Debian maintainers already do that with upstream packages --
> Python might be handled like that too.

I haven't seen *any* complaints about this, so is it possible that
they don't mind having the $Revision: ... $ strings in there?

> The only problem I see if that we need to run the test-suite with a
> -kv'less export.  Fine, this should be part of the release
> procedure.  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.

Hm.  This means that the -kv version gets *much* less testing than the
regular checkout version.  I've done this before in the past with
other projects and I remember that the bugs produced by this kind of
error are very subtle and not always caught by the test suite.

So I'm skeptical.

> Since "smart" means just
> __version__ = [part for part in "$Revision$".split() if '$' not in part][0]
> We can just mandate that, and be safe.

This is less typing, and no more obscure, and seems to work just as
well given that the only two inputs are "$Revision: 1.9 $" or "1.9":

    __version__ = "$Revision: 1.9 $".split()[-2:][0]

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

That's hard right there -- we currently build the Windows compiler
right out of the CVS tree.

> 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.

Who are you telling us how to work?

--Guido van Rossum (home page: http://www.python.org/~guido/)