Rename special display methods and put them lower in priority than display functions

[ellisonbg]

Our new display system uses special methods like __html__, __latex__ to allow objects to declare their representations. We need to rethink how we want to name these methods. Soe ideas are: __repr_html__, __disp_html__, etc.

R. Kern also suggested that these special methods are used after global display functions are attempted.

[rkern]

I also suggest that they not use the __double_underscores__ that are reserved for the Python language itself. :-)

[fperez]

@ellisonbg, this is also on our immediate todo so I made it critical. We should have that protocol sorted out before release (I can also help on that).

[jasongrout]

In the spirit of "Namespaces are one honking great idea -- let's do more of those!", how about prefixing these special ipython methods with an _ipython prefix? For example, I can see Sage having some other assumptions about an __html__ method. Maybe names like _ipython_html or _ipython_latex might make sense. Or maybe collecting these methods into an _ipython_pyout dictionary or object would make sense, so that myvar._ipython_pyout['latex'] or myvar._ipython_pyout.latex would be the ipython latex-formatting function.

[ellisonbg]

There is a danger in not having an ipython prefix in these names.
What do people think about somethign like:

ipython_repr_html
ipython_repr_json

?

Brian

On Sat, Apr 9, 2011 at 8:35 PM, jasongrout
reply@reply.github.com
wrote:

In Sage, some of our special methods have a _sage prefix (think of it like an application namespace), so maybe names like _ipython_html or _ipython_latex might make sense and avoid conflicts with other assumptions about a _latex or _html method.  Or maybe collecting these methods into an _ipython_pyout dictionary or object would make sense, so that myvar._ipython_pyout['latex'] or myvar._ipython_pyout.latex would be the ipython latex-formatting function.

Reply to this email directly or view it on GitHub:
#291 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[jasongrout]

Or here's another idea: _ipython_repr(format='json') or _ipython_repr(format='latex')

[takluyver]

Or, one thing that was suggested before, have a dictionary of mimetype -> method, so we could do:

thing._ipython_repr['text/html']().

This also makes it easy to replace the methods at runtime. The difficulty is that the method references in the dictionary won't be automatically bound on instantiation, so we'd have to find a neat way of handling it.

[ellisonbg]

On Sun, Apr 10, 2011 at 4:41 AM, takluyver
reply@reply.github.com
wrote:

Or, one thing that was suggested before, have a dictionary of mimetype -> method, so we could do:

thing._ipython_repr['text/html']().

The problem with this is that classes that want to implement printing
have to maintain this dictionary. I think it is simpler to rely on
special methods and this pattern is quite familiar to python users.

This also makes it easy to replace the methods at runtime. The difficulty is that the method references in the dictionary won't be automatically bound on instantiation, so we'd have to find a neat way of handling it.

Reply to this email directly or view it on GitHub:
#291 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

[ellisonbg]

This is merged.

[ellisonbg]

Closing...

[jasongrout]

What is merged? Do you happen to have a link to the commit(s)?

[ellisonbg]

e7df0ac
4241df5
43a27cb

On Tue, May 17, 2011 at 9:36 PM, jasongrout
reply@reply.github.com
wrote:

What is merged?  Do you happen to have a link to the commit(s)?

Reply to this email directly or view it on GitHub:
#291 (comment)

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com