gmpy 1.0 for python 2.4 alpha 2 Windows-packaged

[Tim Peters]

[Tim Peters, on the demise of doctest.master]
>> Under a hopeful belief that nobody was using that anyway, I didn't
>> gripe when Edward refactored it out of existence.  This is the first
>> time we've heard that anyone *was* using it!

[Alex Martelli]
> I guess gmpy just wasn't on your radar...!  If you have no need for its
> multi-precision and special-functions support, that's unsurprising.

Since I live on Windows most of the time, I use Marc-Andre Lemburg's
mxNumber.  That comes with a pre-built GMP, so is that much less for
me to screw up.  I generally don't run package test suites on Windows
anyway (the odds that something is uniquely broken on my particular
WIndows box are too low).

>> I suppose we could hack one back in, but I'd rather volunteer to
>> rewrite the gmpy tests to use the stronger 2.4 gimmicks ...

> Thanks, your offer is welcome and gladly accepted -- as long as all the
> tests keep running under 2.3 just as well, of course.  There will be a
> lot of 2.3 around for a long time -- for example, Apple isn't going to
> change the Python version they use in Panther, which is 2.3, at least
> until they come out with Tiger, say in May next year, and since, as
> usual, they'll change $150 or so for the OS upgrade, many people will
> just keep running Panther (and therefore Python 2.3).  Etc, etc.

Nothing against 2.3 here, it's simply a surprise that anyone was using
doctest.master.  SourceForge is down at the moment, so I still don't
know whether gmpy's use was essential or shallow.  If it was
essential, we'll have to hack a master workalike back in.

It could be too that many projects stumbled into using doctest.master,
but none yet bothered to try the 2.4 prereleases.

> I do assume that it's easy to keep the hundreds of tests almost
> unchanged, to avoid having to maintain them separately in two 
> versions, and support 2.3 and 2.4 with localized changes to the
> small spots where the tests are run...?

It should be easy indeed.  Edward Loper and Jim Fulton (by way of
Zope3) had thousands of doctests between them, and Python's test suite
has more than a few too.  None of those doctests had to be changed in
any way.  But none of them used doctest.master.

This next *may* be relevant to gmpy.  I'm aware of it but haven't seen
an instance of it:

"""
>>> 1/0
Traceback (most recent call last):
abc
ZeroDivisionError: integer division or modulo by zero
"""

That doctest passes before 2.4, but no longer.  I don't want to "fix"
that, either, if someone has code like this.

The problem is that a real traceback doesn't look like that.  Python
always indents the lines between the initial "Traceback" line and the
exception detail line.  This is important because 2.4 doctest supports
multiline exception details, so needs a way to guess where the
exception detail starts.  Before 2.4, the exception detail had to fit
on a single line, and doctest's guess was simply "the exception detail
is the last line".  In 2.4, it's "the exception detail starts with the
first line following the Traceback line that's not indented relative
to the Traceback line and that starts with an alphanumeric character".
 That covers all real tracebacks, and the rare but known-to-exist
practice of representing omitted "File" lines with a left-aligned
ellipsis.

Bottom line is that such tests (if any exist) need to be rewritten. 
Starting the "abc" lines with one or more blanks is sufficient so that
the test passes under all versions of doctest.