Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#50 Nicer values visualization

v3.0
closed
Other (25)
5
2007-02-13
2007-02-06
Daniele Varrazzo
No

Values shown by Epydoc may have a better visualization than repr()

This item must not stop v3.0 to be released. Things like "how to best represent a list of dicts" may be taken into account later. But, please, no more <wtf instance at 0xABCD> :)

Here is a list of ideas bounced between edloper and me:

> - repr() is fine only for int and for classes that specifically return a parsable representation, such as datetime. Even floats (such as 0.1) often have an ugly representation.

Yeah -- people are very inconsistent about how they use repr/str.

> - fall back on the parsed version if available and the repr() result matches an ugly pattern looks like "<something>"?

Sometimes the parsed version isn't very trustworthy.. E.g., if they create a variable with a list, and then append to it, etc. But you may be right that this may be the best way to go when you get "<something>". It's almost certainly the best way if you get "<xyz instance at 0xaddr>".

> - fall back on str()ingification?

Yeah, it might be good to use str() for some values.

> - prettyprinting of lists, dicts etc? More clever truncation of long representations?

Seems like good ideas.

One issue/question is that right now a good amount of this is handled in specific docwriter modules.. E.g., the docwriter.html code to colorize regexps. Should this be abstracted away somehow and handled more centrally? E.g., the centralized code could generate an abstract structure saying how to color the regexp, and the individual writers would just translate that to the appropriate markup?

Discussion

  • Edward Loper
    Edward Loper
    2007-02-13

    • status: open --> closed
     
  • Edward Loper
    Edward Loper
    2007-02-13

    Logged In: YES
    user_id=195958
    Originator: NO

    In revision 1477, I've refactored the repr-generation code a little, and hopefully it will address all of the above requirements.

    I refactored the pyval_repr() code, so that now syntax-highlighting
    is done in a central place (epydoc.markup.pyval_repr), and doesn't
    need to be repeated for each output format. In particular,
    APIDoc.pyval_repr() now returns a subclass of ParsedEpydocDocstring.

    The new code does pretty-printing of lists, dicts, strings, tuples,
    sets, frozensets, and regexp objects. This pretty-printing should
    be faster than using the pprint module, in that it short-circuits
    as soon as the the output contains max_lines lines. It also does
    automatic line-wrapping.

    str() is used instead of repr() for floats, ints, longs, and complex
    numbers. Other types could be added to this list, if desired.

    When the pretty-printed representation is constructed, a score is
    calculated that evaluates "how useful" the representation is. If
    it's too low, then the parse-based representation is used instead
    (assuming it's available). In particular, if the string returned
    by an object's __repr__ has the form <.* at 0xaddr>, then epydoc
    will tend to use the parse-based repr instead.