gmpy 1.0 for python 2.4 alpha 2 Windows-packaged

[Tim Peters]

[David Bolen]
> At least when I ran it, the tests themselves (the doctest.testmod)
> calls worked fine.  The rand exceptions seemed to just be a difference
> in reporting in 2.4, for example most of them were of the form:
>
>          - - - - - - - - - - - - - - - - - - - - - - - - -
> Failure in example: r('error',1,2,3)
> from line #2 of gmpy_test_rnd.rand in e:\usr\src\gmpy\test\gmpy_test_rnd.pyc
> Expected:
>    Traceback (most recent call last):
>    File "<string>", line 1, in ?
>    TypeError: function takes exactly 2 arguments (4 given)
> Got:
>    Traceback (most recent call last):
>    TypeError: function takes exactly 2 arguments (4 given)
>          - - - - - - - - - - - - - - - - - - - - - - - - -
>
> However, when I try one of those tests interactively, Python 2.4 seems
> to give me the "File" line too (indented, but it's also indented under
> 2.3, so I'm assuming the lack of indentation is unimportant to
> doctest). 

It's actually crucial <wink>.  I explained the gory details in another
posting.  The bottom line is that the doctest should be changed to
indent the File line, just like it's always been indented in a real
traceback.  doctest in 2.4 cares about this, in order to support an
important new feature (multiline exceptions).  doctests prior to 2.4
didn't care, but they're perfectly happy whether or not that FIle line
is indented.  2.4 needs the indentation, in order to guess where the
exception part starts.

> So I guess I can't say for sure that this isn't something
> impacted by a change in doctest.  The doctest module docs for
> both 2.3 and 2.4 seem to imply it should only be checking the
> exception type/value

That's true.

> (the last line),

That's not -- in 2.4 it can span any number of lines.  From the
current 2.4 docs:

    Each line of the traceback stack (if present) must be indented further
    than the first line of the example, or start with a non-alphanumeric
    character. The first line following the traceback header indented the
    same and starting with an alphanumeric is taken to be the start of
    the exception detail. Of course this does the right thing for genuine
    tracebacks.

    Changed in version 2.4: The ability to handle a multi-line exception
    detail was added. 

The good news is that it should be dead easy to fix.