 |
 |
 |
Python Library Reference |  |
 |
 |
>>> foo()
{"Hermione": "hippogryph", "Harry": "broomstick"}
>>>
is vulnerable! One workaround is to do
>>> foo() == {"Hermione": "hippogryph", "Harry": "broomstick"}
1
>>>
instead. Another is to do
>>> d = foo().items()
>>> d.sort()
>>> d
[('Harry', 'broomstick'), ('Hermione', 'hippogryph')]
There are others, but you get the idea.
Another bad idea is to print things that embed an object address, like
>>> id(1.0) # certain to fail some of the time 7948648 >>>
Floating-point numbers are also subject to small output variations across platforms, because Python defers to the platform C library for float formatting, and C libraries vary widely in quality here.
>>> 1./7 # risky 0.14285714285714285 >>> print 1./7 # safer 0.142857142857 >>> print round(1./7, 6) # much safer 0.142857
Numbers of the form I/2.**J are safe across all platforms, and I
often contrive doctest examples to produce numbers of that form:
>>> 3./4 # utterly safe 0.75
Simple fractions are also easier for people to understand, and that makes for better documentation.
If you have module-level code that must only execute once, a more foolproof definition of _test() is
def _test():
import doctest, sys
doctest.testmod()
'0' and
'1' to 'False' and 'True' in Python 2.3.
This makes it clumsy to write a doctest showing boolean results that
passes under multiple versions of Python. In Python 2.3, by default,
and as a special case, if an expected output block consists solely
of '0' and the actual output block consists solely of
'False', that's accepted as an exact match, and similarly for
'1' versus 'True'. This behavior can be turned off by
passing the new (in 2.3) module constant
DONT_ACCEPT_TRUE_FOR_1 as the value of testmod()'s
new (in 2.3) optional optionflags argument. Some years after
the integer spellings of booleans are history, this hack will
probably be removed again.
|
|
|
Python Library Reference | |
|
|