Issue764504
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2003-07-02 10:30 by average, last changed 2022-04-10 16:09 by admin. This issue is now closed.
Messages (5) | |||
---|---|---|---|
msg16800 - (view) | Author: Mark J (average) | Date: 2003-07-02 10:30 | |
#mymod.py: class base(dict): myupdate = dict.update #FINE def myfunc(self): pass class derive(base): myname = base.myfunc #FAILS import doctest, mymod doctest.testmod(mymod) ****** $ python2.3b2 mymod.py Traceback (most recent call last): File "mymod.py", line 8, in ? import doctest, mymod File "/home/me/mymod.py", line 9, in ? doctest.testmod(mymod) File "/usr/local/lib/python2.3/doctest.py", line 1137, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/local/lib/python2.3/doctest.py", line 900, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/local/lib/python2.3/doctest.py", line 1061, in __runone return self.rundoc(target, name) File "/usr/local/lib/python2.3/doctest.py", line 820, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/local/lib/python2.3/doctest.py", line 929, in run__test__ raise TypeError("Tester.run__test__: values in " TypeError: Tester.run__test__: values in dict must be strings, functions or classes; <unbound method base.myfunc> ****** Does not appear to be specific to Python v2.3. Thanks! Mark |
|||
msg16801 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2003-07-09 05:48 | |
Logged In: YES user_id=80475 Tim, would you like me to fix this one by searching the unbound method or by skipping the unbound method? Since classes are searched recursively, it may be reasonable to search the unbound method. However, imports are not searched, so there is a precedent for skipping it. |
|||
msg16802 - (view) | Author: Tim Peters (tim.peters) * | Date: 2003-07-16 21:08 | |
Logged In: YES user_id=31435 If it has to be fixed <wink>, the only principle I can conjure up is that redundant testing is a waste of time and surprising. On that ground, in the specific example I'd rather skip it, since if the thing had a doctest, it would be most natural to run it from base.myfunc.__doc__. If you're feeling more ambitious, I recently slammed in some useful doctest extensions from Jim Fulton. As I know you've already discovered, there are some warts. The deepest wart isn't obvious: Jim's extensions use their own ways of finding doctests to run. It would be good if everthing used the same ways of finding doctests to run. This bug report shows that doctest's old ways don't always work. It's unknown in how many situations the new ways don't work, and/or deliver different results. |
|||
msg16803 - (view) | Author: Raymond Hettinger (rhettinger) * | Date: 2003-07-17 06:27 | |
Logged In: YES user_id=80475 Agreed. There is no compelling use case for changing this in Py2.3. Marking as postponed. For Py2.4, there will be plenty of time for merging/improving the underlying search behaviors. |
|||
msg16804 - (view) | Author: Tim Peters (tim.peters) * | Date: 2004-08-08 03:06 | |
Logged In: YES user_id=31435 The example no longer complains in 2.4 doctest.py, so closing as Fixed. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:09:38 | admin | set | github: 38770 |
2003-07-02 10:30:55 | average | create |