Make it easier to support new data types in the variable explorer

[jitseniesen]

This comes from the discussion at #7042 but has popped up various times in the past. It should be easier to support new data types in the variable explorer. Ideally, a user should be able to do this without knowing much about the Spyder internals.

We probably first need to discuss how to achieve this.

[jitseniesen]

One idea, from @hgijeon, is to specify how a new data type can be converted to a data type that Spyder already knows about. In the example, a variable of type torch.Tensor can be converted to a numpy array by applying '.numpy()' .

A related issue is #6338 (Can 'Supported Data Types' be customized?); currently, as a fallback when displaying an unsupported data type we convert it to a string and display that.

A related comment from @CAM-Gerlach:

some type of modular "plugin" support for the variable explorer's Editor classes. It would be really need to have, but would take some work, requiring refactoring the existing Editors into a modular system and creating an API to interact with third-party editors, etc.

As somewhat of a stopgap between the quick but specific and general but more involved approaches could be Pythonic duck typing, converting unknown types to known ones (principally array, and maybe list) and regressing to the current behavior if an exception, but not sure if it would be worth the tradeoffs vs. checking against a list of types that can be converted to array, list etc. by various means.

The more custom types we supported though, the more we'd want to have the option to view any object as a generic low level __dict__ to see and interact with all its properties, along with the higher-level view we currently use when available—I've been thinking about something like this for a while, since somethings while working the former can be convenient, especially when working with derived types and convertible ones like this

The last suggestion is similar to #558 (Add Object Explorer for exploring an object's properties).

[CAM-Gerlach]

The last suggestion is similar to #558 (Add Object Explorer for exploring an object's properties).

I guess to clarify, the last suggestion is probably a separate (and much easier), though somewhat related issue, and is really more about having an additional option to to manually trigger opening an object in the generic object explorer that we already have (vs. only its autodetected data type and type-specific high level editor), as opposed to creating a newer, fancier hierarchical version with classes and inheritance as #558 .