#159 Bad global name generation in parsing

[Daniele Varrazzo]

Hi,

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.

Daniele

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

[Daniele Varrazzo]

[Edward Loper]

Logged In: YES
user_id=195958
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
user_id=1053920
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]

Logged In: YES
user_id=1053920
Originator: YES

Patch applied in r1435.