allow NotImplementedError in formatters - #4832

Make sens. Would you like to add handeling for returning NotImplemented ?

Would you like to add handling for returning NotImplemented?

No, returning NotImplemented is only for overriding comparison methods, not for general use.

No, returning NotImplemented is only for overriding comparison methods, not for general use.

Ok. I could argue that Python does not have "rich representation" and that the Python doc use the term "rich comparaison" (sic).

@minrk: I'm curious: what sources suggest that NotImplemented is not for general use, especially in situations like rich comparison, when you want to signal that the system should try some other ways to accomplish a result?

@Carreau It is a similar case, sure. But we do not handle it in the way Python comparison handles NotImplemented, which is to proceed with dispatch as if that entry didn't exist.

@jasongrout Python docs. It doesn't say it's specifically to be avoided elsewhere, but it does describe the case for which it exists, and I have not seen it used for anything else.

@jasongrout I don't feel strongly, it just seems like a sufficiently rare pattern that we should only handle the more common one. If the NotImplemented singleton is more common outside of comparison methods than I thought, I have no problem using it.

I'm fine with not handeling NotImplemented, we can put that on dev meeting agenda.

I don't feel strongly about it either, but I do feel like handling NotImplemented is a nice solution in the discussion on _ipython_display_ and the _repr_* framework.

I don't feel strongly about which we use, but I do think we should use just one of NotImplemented or NotImplementedError - allowing both just makes the API more confusing.

I'm coming around to NotImplemented in terms of basic design, which @jasongrout prefers, but there's one point where NotImplementedError has a big advantage: it's backward-compatible. Returning NotImplemented will raise a TypeError in IPython json serialization, whereas raising NotImplementedError will have the same behavior in 1.0 and 2.0. For that alone, if we pick just one, I think it should be NotImplementedError, even if it is the less elegant.

We discussed NotImplemented vs NotImplementedError in the dev meeting yesterday, and agreed to stick with NotImplementedError for the reason Min gives above.

@minrk, is there anything else you want to do before we merge this?

Nope, it should be all set.

I'm noticing that executing a cell that raises such an error pops up a Formatter warning on first execution
but repeated execution of the same cell or the same code in a new cell does not produce a warning.

Is that intentional?