gmpy 1.0 for python 2.4 alpha 2 Windows-packaged

[Bengt Richter]

On Sat, 4 Sep 2004 20:09:38 -0400, Tim Peters <tim.peters at gmail.com> wrote:

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

Just a thought re traceback printed representation, while you're at it:
A traceback from an exception in a recursive call is apt to have repeated lines
that could be replaced by the first followed by an repeat count indication. E.g.,

 >>> def foo(x): 1.0/x; foo(x-1)
 ...
 >>> foo(3)
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 1, in foo
   File "<stdin>", line 1, in foo
   File "<stdin>", line 1, in foo
   File "<stdin>", line 1, in foo
 ZeroDivisionError: float division
 >>> foo(1)
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 1, in foo
   File "<stdin>", line 1, in foo
 ZeroDivisionError: float division
 >>> foo(0)
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 1, in foo
 ZeroDivisionError: float division

Repetitions are particularly useless when the stack blows totally, and you
get ~1k repetitions (how do you write a doc-test for the traceback of that?)

Just at thought. (I'm old enough to remember *gap* or such in line printer
listings with lots of otherwise repeating lines, before we had the luxury
of capturing  hundreds of megabytes of printing to RAM on our own PCs ;-)

Regards,
Bengt Richter