Formatters #195

Merged
14 commits merged into from Nov 3, 2010

Conversation

Projects
None yet
3 participants
Contributor

rkern commented Oct 29, 2010

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.

Owner

fperez commented Oct 31, 2010

Some comments:

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!

Contributor

rkern commented Oct 31, 2010

Re: #L0R206: Should I move that logic to write_result_repr()? That's the "client-side implementation" for the default terminal console.

Owner

fperez commented Oct 31, 2010

Sure! Thanks. With that and the other fixes, I think we can go ahead.

rkern added some commits Oct 31, 2010

@rkern rkern BUG: Format according to the coding standard. 393a1a0
@rkern rkern BUG: docstring typo. 3662d07
@rkern rkern 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.
c77a02a
Contributor

rkern commented Oct 31, 2010

My branch now has these fixes.

Owner

fperez commented Oct 31, 2010

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!

Owner

fperez commented Nov 3, 2010

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):

import sure


(1).should.equal(1)

"SOME_STRING".lower().should.equal("some_string")

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:

http://f.cl.ly/items/43061t3b361o2G2l3K2K/ipython-part1.png

http://f.cl.ly/items/2a3H383V421I110r290m/ipython-part2.png

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

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment