#159 Bad global name generation in parsing



i've been trying to nail this bug, but the behavior of docparser._global_name() is not clear to me, so i prefer to discuss about it.

I found the issue trying to generate api docs for the twisted package by parsing. The offending situation is summarized by the attached package.

Briefly, in the twisted.manhole module there is the following class declaration:

from twisted.application import service

class Service(service.Service):

when the base classes are being inspected, "service.Service" must be translated into a global name, but it is erroneously transformed into "twisted.manhole.service.Service". The inheritance tree becomes a graph with a loop which eventually leads to a runtime error for excessive recursion depth.

To reproduce the bug, unpack the attached package and parse it using:

epydoc --parse-only twis

You can put a breakpoint on docparser.py:954 (rev. 1418): it will stop right before the wrong call.


p.s. this bug category should be "parsing"


  • Daniele Varrazzo

  • Daniele Varrazzo

    • labels: 469725 --> source parsing
  • Edward Loper

    Edward Loper - 2007-02-03

    Logged In: YES
    Originator: NO

    I believe that the problem is actually in the find_base() method. I propose the following fix:

    --- src/epydoc/docparser.py (revision 1428)
    +++ src/epydoc/docparser.py (working copy)
    @@ -1571,8 +1571,10 @@
    . src = lookup_name(name[0], parent_docs)
    . if (src is not None and
    . src.imported_from not in (None, UNKNOWN)):
    - _import_var(name, parent_docs)
    - base_var = lookup_variable(name, parent_docs)
    + base_src = DottedName(src.imported_from, name[1:])
    + base_var = VariableDoc(name=name[-1], is_imported=True,
    + is_alias=False, imported_from=base_src,
    + docs_extracted_by='parser')
    . # Otherwise, it must have come from an "import *" statement
    . # (or from magic, such as direct manipulation of the module's
    . # dictionary), so we don't know where it came from. So

    I.e., rather than using _import_var to try to import the variable, just create a variable that's marked as imported, and asssume that the linker can link that variable to an appropriate value.

    If this looks good to you, I'll go ahead and apply it. (It generates the correct output for your example code, but I haven't tested it much on other examples.)

  • Daniele Varrazzo

    Logged In: YES
    Originator: YES

    Ok, it seems to solve the problem. The twisted package could be completely parsed (introspection doesn't work but that's another story...)

  • Daniele Varrazzo

    • status: open --> closed-fixed
  • Daniele Varrazzo

    Logged In: YES
    Originator: YES

    Patch applied in r1435.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks