#149 Favoring parsed representation over the Python value

closed-fixed
inspection (59)
5
2007-02-28
2007-01-04
No

Hi,

I love epydoc, but I've found it difficult to get it to generate appropriate output for my project without patching it. In this particular instance, I was getting a lot of Class Variables whose values were showing up like:

<Number object at 0xb7a718b4>

when I used introspection only, and as the much more readable:

Number(default= 1.0, doc= "Scaling factor applied to all sub-patterns.")

when I used parsing only. But I can't use parse-only in general, because the docstrings for my classes (as reported in a previous bugreport or mail message) do not show up in that case.

What I have done for now is to patch the 3.0alpha3 version so that the html docwriter always favors the parsed representation for variable values (which seemed to work fine), even when introspected values are available.

Would it make sense to include a command-line switch to allow other users to do this? In very many cases the results are quite different, so I imagine that many users might want to choose one or the other, without giving up any of the other information available through introspection.

In case it helps, I've attached my patches to 3.0alpha3, though I think a command-line switch would be much more useful than the patches to docwriter/html.py. (The patches to docintrospector.py are for similar reasons mentioned earlier, to get the __doc__ string available for my custom objects even though there is no __doc__ variable in the source code...)

Discussion

  • James A. Bednar

    James A. Bednar - 2007-01-04

    Patch to epydoc-3.0alpha3

     
  • Daniele Varrazzo

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

    Logged In: YES
    user_id=1053920
    Originator: NO

    I added the simple euristic that if the introspected value is in a form like:

    <Number object at 0xb7a718b4>

    the parsed value is preferred, if available.

    More to be done on the front of values representation, but this simple case should be fixed.

    Please report if it works correctly for you.

     
  • Edward Loper

    Edward Loper - 2007-02-13

    Logged In: YES
    user_id=195958
    Originator: NO

    r1477 further improves on the fixs that Daniele made.

     
  • Edward Loper

    Edward Loper - 2007-02-13
    • status: open-fixed --> pending-fixed
     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    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
     
  • James A. Bednar

    James A. Bednar - 2007-04-16

    Logged In: YES
    user_id=43908
    Originator: YES

    Thanks for taking care of this! I've updated to the latest released version, which appears to have been made after the changes mentioned in this thread were applied. It now does seem to work correctly for me, in that I can now remove my custom patch and the Class Variable Details section now shows a reasonable value for each item, instead of something like <package.module.class object at 0x...>.

    However, the Class Variables section still shows <package.module.class object at 0x...> for the same objects that show up properly for the Class Variable Details section. Maybe there was a fix made in only one place that should have been made in two places?

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks