SourceForge has been redesigned. Learn more.

#198 Exception: unicode + instance


Traceback (most recent call last): Progress: 00:12
File "/usr/bin/epydoc", line 13, in ?-------------------------------------]
cli() Parsing docstrings: weakref.WeakValueDictionary
File "/usr/lib/python2.4/site-packages/epydoc/", line 949, in cli
main(options, names)
File "/usr/lib/python2.4/site-packages/epydoc/", line 741, in main
File "/usr/lib/python2.4/site-packages/epydoc/", line 261, in build_doc_index
parse_docstring(val_doc, docindex)
File "/usr/lib/python2.4/site-packages/epydoc/", line 239, in parse_docstring
field.arg(), field.body())
File "/usr/lib/python2.4/site-packages/epydoc/", line 555, in process_field
handler(api_doc, docindex, tag, arg, descr)
File "/usr/lib/python2.4/site-packages/epydoc/", line 756, in process_ivar_field
set_var_descr(api_doc, ident, descr)
File "/usr/lib/python2.4/site-packages/epydoc/", line 840, in set_var_descr
TypeError: unsupported operand type(s) for +: 'instance' and 'unicode

You can get the code I was trying to document by:

svn co lsr

Command I used was the following:

epydoc -o api -v --debug src/*.py \ $(find src/ -name | cut -d / -f -2 | sort | uniq)


  • Edward Loper

    Edward Loper - 2007-09-23
    • milestone: --> v3.0
  • Edward Loper

    Edward Loper - 2007-09-23

    Logged In: YES
    Originator: NO

    I suspect that this bug has the same underlying cause as bug 1682525

    Namely, some object is not getting assigned a canonical name. The code in epydoc.docbuilder.assign_canonical_names is *supposed* to ensure that every reachable apidoc object has a canonical name, but something must be slipping through the cracks somewhere. Try wrapping the failing statement in a try/except block, and then printing the value of "api_doc", and or "api_doc.pyval". You can do this most easily using log.error():

    canonical_name = ...

    If you let us know what the value is, and what you would expect the "canonical name" for that object to be (namely, the path by which it can be reached from the root), it would help us figure out what the problem is.

  • Edward Loper

    Edward Loper - 2007-09-25

    Logged In: YES
    Originator: NO

    Ok, I've tracked down the cause of this bug. It happens when:

    a) a package's submodule becomes shadowed by a variable.

    b) the submodule is introspected & put into the cache of introspected values as part of introspecting some other value, before epydoc tries to introspect the module directly.

    I'll start trying to figure out a good way to fix this.

  • Edward Loper

    Edward Loper - 2007-09-25
    • status: open --> pending-fixed
  • Edward Loper

    Edward Loper - 2007-09-25

    Logged In: YES
    Originator: NO

    This bug should be fixed now, in svn revision 1648.

    If you get a chance, please test it to make sure.

  • SourceForge Robot

    Logged In: YES
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

  • SourceForge Robot

    • status: pending-fixed --> closed-fixed

Log in to post a comment.