Expose a _simpler_ way to get raw object reprs

This came up in several contexts, @mpacer for subfigure and @rgbkrk who want to have list(objects) have rich reprs.

We can’t call _repr_*_ recursively as it may not be defined (user custom reprs, or repr_mimebundle). and get_ipython().display_formatter.format is bit verbose/hidden.

I propose a small wrapper around get_ipython().display_formatter.format, which is exposed and return the repr of an object. It has to likely have some logic to check for re-entrancy (like repr pretty) and avoid recursion.

Thoughts ?

[ellisonbg]

With JupyterLab we are working hard to provide a lot of clarity about what things are public APIs and which things are not. The approach (how it turned out) in the classic notebook was to have users directly modify the DOM and target our CSS classes in extensions. The difficulty with that is that essentially makes your DOM structure and CSS classes public APIs, which is overly constraining from a maintenance perspective. With Lab, our policy is that the DOM structure and CSS classes are entirely private. As Kyle mentioned, this type of thing also makes it difficult for other frontends to cover these cases.

I agree with Kyle that if we were to ever standardize on DOM structure or CSS classes, it would need to be in both specs (nbformat, message spec). However, I don’t think that is the best way to get something like this working across frontends. Some other options:

• Just return application/json and let the tree renderer handle it.
• Return HTML, but with its own well scoped CSS inline.
• Create a new MIME type that we can all build renderers for.

I prefer any/all of these over the CSS class standardization.

On Wed, Jun 14, 2017 at 4:44 PM, Brian Granger [e-mail] wrote:

I am not in favor of standardizing CSS class names or DOM structures…out with kids will write more later…

On Wed, Jun 14, 2017 at 12:32 PM, Kyle Kelley [e-mail] wrote:

Why in the spec ?

The text/html and application/javascript mimetypes have this implicit support / ability from the classic notebook that has been a bit of a pitfall with other frontends (especially as libraries code for it).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ipython/ipython/issues/10647#issuecomment-308534612, or mute the thread https://github.com/notifications/unsubscribe-auth/AABr0EX4k1HoJPtm2faP5UYJBXUVsLNlks5sEDU1gaJpZM4N03rG .

– Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [e-mail] and [e-mail]

– Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [e-mail] and [e-mail]

[Carreau]

With JupyterLab we are working hard to provide a lot of clarity about what things are public APIs and which things are not. The approach (how it turned out) in the classic notebook was to have users directly modify the DOM and target our CSS classes in extensions. The difficulty with that is that essentially makes your DOM structure and CSS classes public APIs, which is overly constraining from a maintenance perspective. With Lab, our policy is that the DOM structure and CSS classes are entirely private. As Kyle mentioned, this type of thing also makes it difficult for other frontends to cover these cases.

Thanks, I was not at all speaking of already existing class, currently existing DOM structures, or of Dom even structures created by the frontend. The above example cannot be rendered only by a tree rendered that handle json. Creating a new mimetype does not work either. And “Well scoped” css cannot work cleanly either with current architecture as each leaf node would have to display a duplicate of the 80 line css fixes to render identically on Lab/Nteract/Classic.