gmpy 1.0 for python 2.4 alpha 2 Windows-packaged

[Alex Martelli]

Thanks to David Bolen, who did the build, I have been able to make
available a win32 packaging for gmpy 1.0 on python 2.4 alpha 2 (should
work on any later Python 2.4 as well, but I have no way to check it at
all). I can't reach sourceforge at the moment, so I have meanwhile put
the exe file up at:

http://www.aleax.it/Python/gmpy-1.0.win32-py2.4.exe

Users of both gmpy and python 2.4 on windows are invited to dowload and
install this, try it out, and let me know. There are a few known
glitches David tells me about:
"""
It seems to pass the tests (other than the scan ones noted)
with the exception of a bunch gmpy_test_rnd.rand due to changing
traceback output in 2.4. I also had to remove the use of doctest.master
since it looks like that's deprecated in 2.4 (it's no longer exported
by the module's __all__).
"""

Thanks to David, and to any users who can help me out, since I can't do
any testing on this build myself!


Alex

 

[Tim Peters]

[Alex Martelli]

...
There are a few known glitches David tells me about:
"""
It seems to pass the tests (other than the scan ones noted)
with the exception of a bunch gmpy_test_rnd.rand due to changing
traceback output in 2.4. I also had to remove the use of
doctest.master since it looks like that's deprecated in 2.4 (it's no
longer exported by the module's __all__).
"""

Ya, Edward Loper, Jim Fulton and I have made massive changes to
doctest for 2.4, refactoring it mercilessly.

doctest.master was a poorly documented attempt at starting to build a
framework for managing multiple tests, but as far as I knew it was
entirely unused -- all the heavy doctest users I knew about used
unittest frameworks, and so 2.4 has grown stronger ways of working
with unittest drivers instead. It's also grown much saner "doctest
runner" kinds of classes as part of that, as opposed to the old
doctest.master global. 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!

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

 

[Alex Martelli]

...
doctest.master global. 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!

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.

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.

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


Alex

 

[David Bolen]

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

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). 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 (the last line), so I guess I don't know why it's failing.
At least to me it seems clearly to be the right exception.

The one failure that I don't think you could easily anticipate is a
change in the actual exception message - for example the "r('shuf',
'astring')" test wants a TypeError saying "object doesn't support item
assignment", but 2.4 changes that to "object does not support item
assignment".

-- David

 

[Alex Martelli]

The one failure that I don't think you could easily anticipate is a
change in the actual exception message - for example the "r('shuf',
'astring')" test wants a TypeError saying "object doesn't support item
assignment", but 2.4 changes that to "object does not support item
assignment".

Yeah, doctest IS prone to this sort of issue, sigh -- wording of error
messages keeps changing, in ways either subtle or major. I gather that
2.4 doctest has a "skip" indicator (an ellipsis I believe) to help with
that, but I don't want to break compatibilty with 2.3...


Alex

 

[Tim Peters]

[David Bolen]
...
[Alex Martelli]

Yeah, doctest IS prone to this sort of issue, sigh -- wording of error
messages keeps changing, in ways either subtle or major. I gather that
2.4 doctest has a "skip" indicator (an ellipsis I believe) to help with
that, but I don't want to break compatibilty with 2.3...

Darn. The new doctest ELLIPSIS directive is a good long-term approach
to this, but you're right that it doesn't help you today. So, in the
*next* Python 2.4 prerelease, there will be a new
IGNORE_EXCEPTION_DETAIL directive. Then, e.g., this doctest passes
under 2.3.4 and 2.2.3, and will also pass in 2.4:

(1, 2)[3] = 'moo' #doctest: +IGNORE_EXCEPTION_DETAIL

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment

Since doctest directives didn't exist before 2.4, earlier Pythons view
them as comments, and insist on exact match. 2.4 will still insist on
seeing a TypeError, but won't care that "doesn't" has changed to "does
not" (or, for that matter, won't care if the actual detail is
"Congratulations, Anna and Alex!").

After Pythons prior to 2.4 become uninteresting, a less forgiving test
can be gotten via, e.g.,

(1, 2)[3] = 'moo' #doctest: +ELLISPSIS

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object does... support item assignment

 

[Tim Peters]

[Tim Peters, on the demise of doctest.master]
[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).

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:

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

 

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

 

[Bengt Richter]

[Tim Peters, on the demise of doctest.master]
[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).

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:

"""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.,
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
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in foo
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

 

[Alex Martelli]

IGNORE_EXCEPTION_DETAIL directive. Then, e.g., this doctest passes
under 2.3.4 and 2.2.3, and will also pass in 2.4:

(1, 2)[3] = 'moo' #doctest: +IGNORE_EXCEPTION_DETAIL

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment

Since doctest directives didn't exist before 2.4, earlier Pythons view
them as comments, and insist on exact match. 2.4 will still insist on
seeing a TypeError, but won't care that "doesn't" has changed to "does

GREAT solution!

not" (or, for that matter, won't care if the actual detail is
"Congratulations, Anna and Alex!").

Heh -- thanks!

After Pythons prior to 2.4 become uninteresting, a less forgiving test
can be gotten via, e.g.,

(1, 2)[3] = 'moo' #doctest: +ELLISPSIS

Wow -- typo-tolerant, too?-)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object does... support item assignment

Right, unless 2.5 changes the error text to "objects of type tuple do
not support item assignment" or some other clarificatory rewording, of
course. In practice, my doctests that are meant to survive across
Python releases will become heavy users of IGNORE_EXCEPTION_DETAIL!-)


Alex

 

[Alex Martelli]

[Tim Peters, on the demise of doctest.master]
[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

So does gmpy in the prebuilt-for-Windows version, btw. I may even have
snagged that from Marc Andre's package at some time in the past...

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

Hmmm -- what you mean by Windows and what I mean by Windows must be very
different OS's. Has DLL Hell disappeared since I finally stopped
working as a Windows guru and turned to Linux, Mac OS X, OpenBSD and
other OS's...?-)

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.

Probably shallow. Anyway, I'll be glad to mail you a gmpy package if SF
keeps giving problems, let me know!

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

I hadn't, for example -- even though I've been current on 2.4 for a long
time, I hadn't thought of building gmpy for it (shame on me!).

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.

Ah... well, let's hope my use was indeed shallow!

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

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

OK, inserting blanks if needed doesn't seem too difficult a fix, I
agree!


Alex

 

[Aahz]

Darn. The new doctest ELLIPSIS directive is a good long-term approach
to this, but you're right that it doesn't help you today. So, in the
*next* Python 2.4 prerelease, there will be a new
IGNORE_EXCEPTION_DETAIL directive. Then, e.g., this doctest passes
under 2.3.4 and 2.2.3, and will also pass in 2.4:

(1, 2)[3] = 'moo' #doctest: +IGNORE_EXCEPTION_DETAIL

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: object doesn't support item assignment

Since doctest directives didn't exist before 2.4, earlier Pythons view
them as comments, and insist on exact match. 2.4 will still insist on
seeing a TypeError, but won't care that "doesn't" has changed to "does
not" (or, for that matter, won't care if the actual detail is
"Congratulations, Anna and Alex!").

Huh. The advice I've always seen is, "Never rely on the text of an
exception -- it can change even in bugfix releases."