gmpy 1.0 for python 2.4 alpha 2 Windows-packaged

Tim Peters tim.peters at gmail.com
Sat Sep 4 13:06:53 EDT 2004


[David Bolen]
 ...
>> 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".

[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



More information about the Python-list mailing list