Add __str__ (or __repr__) to Workspace class

[cbrnr]

It would be nice if printing a Workspace object showed some basic information. I'm never sure if __print__ or __repr__ should be used for this purpose though.

[mbillingr]

I think __repr__ and __str__ should be used for this purpose.

For the summary __str__ is better, because __repr__ should be a representation of the object that can be used to reconstruct it by evaluating the string.

The workspace already implements a very basic __str__, which could be enhanced.

[cbrnr]

Ah, I didn't see that. Currently, you need to print(ws) in order to see this info. However, it would be great if this was also shown when just typing the object in the interactive interpreter, i.e. ws. I assume this would work if we move the implementation of __str__ to __repr__?

[mbillingr]

Right. Ipython seems to show __repr__ and not __str__. We could change that (I think __str__ falls back to __repr__when unimplemented, so it's enough to implement one of those), but let's first find out if it is good practice to show a summary in __repr__.

[cbrnr]

Yes, it is. It seems like __repr__ should always be implemented. Printing an object falls back to __repr__. If you need a clearer textual representation, use __str__ to create a modified version of the info in __repr__. Bottom line: yes, let's move our __str__ implementation to __repr__. See e.g. https://stackoverflow.com/questions/1436703/difference-between-str-and-repr-in-python.

[mbillingr]

Does this answer the question if it is good or bad practice to show only a summary in __repr__ without fully representing the instance?

(I can't check stackoverflow at the moment, because I'm in a hotel and for some reason only https:// sites work.)

[cbrnr]

More or less. https://stackoverflow.com/questions/1436703/difference-between-str-and-repr-in-python

[mbillingr]

I take the as essintial point that eval(repr(ws)) == ws holds. This will be difficult in our case because the workspace contains EEG and source data.

Do you think it's ok to violate this principle?

In this case we could create a __repr__ that shows the information in a somewhat compressed form (i.e. one liner), and a __str__ that shows a nicely formatted version of the same information. Or we use only __repr__ and to hell with standards :)

[cbrnr]

In Python, we're most often talking about conventions and not standards - and that's a good thing :-).

It makes sense to go with what everybody does. I can't decide right now, because I need to dig deeper into this topic (I don't particularly like the SO post I linked, it was just the first one I found). Let's try to figure this out before we decide how to proceed.

[mbillingr]

We can also simply do it the way we like and wait to see if somebody complains :)

[cbrnr]

Yes. Since we can't make __repr__ a valid Python expression which recreates the object, we should show some basic info instead on one line. The __str__ method could then remain to show more detailed info about the object.

[mbillingr]

We could create a __repr__ that shows the arguments used to construct this particular workspace object. This includes VAR parameters, backend, ... everything you can pass to the constructor. This does not include data, sources, residuals, etc.

In contrast, the __str__ method could show the same information and provide additional summaries about the data (dimensions), fitted VAR model (order, regularization, residuals), source activations (amount), etc.

[cbrnr]

Yes! Perfect! I will take care of that in a PR.