Here is the start of the formatter implementation. It defines a FormatterABC and implements a DefaultFormatter that uses pretty. The DefaultFormatter can be configured in ipython_config.py. I have extended the messaging spec to include a list of extra formats in the pyout message.
Incidentally, I ported the _x_default() feature from Traits to traitlets. It's just too useful to not have. I also fixed a bug concerning the merging of the MetaHasTraits and MetaQObject metaclasses.
ENH: Add dynamic initializers (_x_default methods) to traitlets.
ENH: Refactor pretty to allow it to run without global type registries.
ENH: Implement and test the default pretty formatter.
ENH: Allow configurability of the DefaultFormatter and the DisplayHook.
ENH: Documentation for configuring the DefaultFormatter.
BUG: Explicitly merge the __init__ and __new__ metaclass methods for …
…MetaQObjectHasTraits. The MetaHasTraits code was not being executed previously.
ENH: Use text/plain for the format string of the DefaultFormatter.
BUG: Return None if repr() fails.
ENH: Extend the DisplayHook.compute_result_repr() and write_result_re…
…pr() methods to produce and consume the lists of extra formats. Use this capability in the ZMQ shell. Document the extension to the messaging format.
The output should just be sent to the client without further modification, and only the client should be responsible for deciding how to display it. Eventually, even the checks for any newlines shouldn't be there, as some clients may display prompts in a separate box so that they don't need to worry about newlines. But don't remove those yet, as the terminal client code would need to be fixed accordingly, so that's probably best done elsewhere (unless you want to commit to the whole cleanup job).
These are minor points, once taken care of it looks good to me. Thanks!
Re: #L0R206: Should I move that logic to write_result_repr()? That's the "client-side implementation" for the default terminal console.
Sure! Thanks. With that and the other fixes, I think we can go ahead.
BUG: Format according to the coding standard.
BUG: docstring typo.
BUG: For multiline outputs, conditionally prepend a newline if necess…
…ary. Move this code to where we actually write the output. Frontends should be able to decide whether to use this or not.
My branch now has these fixes.
OK, great. Good to go as far as I'm concerned. Since we had a long discussion about this one, let's give it a day or two so others have a chance to take a look. But after that, go ahead and push it.
Thanks for taking the time for a full discussion!
DOC: Add copyright comments.
BUG: Remove the pretty extension as it is now obsolete.
OK, I went ahead and pushed, if anyone has further ideas we can always polish it later. Thanks for the great work!
Just out of curiosity, I could not find why this else is necessary.
I wrote an assertion library called sure that allows writing python tests like this (CPython only):
the problem is that because sure adds a number of methods and properties to the object type, I need to implement the __dir__ method of the object class in order to remove references to the sure-specific method and attributes (e.g: should, have, does etc).
All works fine in sure after those changes I had to made, the only exception I found so far was in IPython, which raises the TraitError exception below
See an example here:
I wonder if it has something to do with #405
BTW in order to test ipython against that scenario all you need is to install sure version 1.2.0
The change I made is here.
I sent the pull request #3021 that fixes it