__repr__ and __str__ for models

[pmli]

This includes some basic __repr__ and __str__ methods for models. Comments are welcome.

Closes #392.

[sdrave]

I see that you have decided to let __str__ and __repr__ behave quite differently. Actually, I am not really sure what we want here. I know that it is recommended practice to let the result of __repr__ be mostly equivalent to the Python code needed to instantiate the object while __str__ should give a nice string representation. However, our objects might be a little too complex for such a __repr__ implementation. In particular, if proper __repr__ functions are implemented for operators as well. (Think of a parameterized problem, where multiple operators are (probably nested) LincombOperators.) Also, I am not sure if we really want to print all (optional) arguments of the construtor call.

@pymor/pymor-devs , what do you think?

[pmli]

Ok, I'm actually fine with using __repr__ for "pretty printing" to avoid using print. I wasn't sure how much we want (or how much it makes sense) to follow the conventions (__repr__, __str__).

[sdrave]

This is really something, where I am not sure what the right thing is. Maybe someone else also has an opinion, @pymor/pymor-devs?

[renefritze]

I also think it's fine to break from the __repr__ rule for those kinds of complex objects.

[pmli]

@pymor/pymor-devs How about first adding __str__ in this PR and later discuss __repr__? I would like to hear what do you think print(model) should look like for StationaryModel and InstationaryModel (and iosys models if you have ideas).

[sdrave]

I guess for StationaryModel i would like something like

f'''
StationaryModel {self.name if self.name != 'StationaryModel' else ''}
    parameter_space: {self.parameter_space}
    solution_space: {self.solution_space}
    operator: {self.operator}
    rhs: {self.rhs}
'''

If the str of self.operator or self.rhs has multiple lines, it should be indented accordingly.

[pmli]

How about separating this PR into one about __repr__ and one about __str__?

[sdrave]

With #706 merged, how do we want to proceed here? I think it is clear that we won't need a custom __repr__ for Models. What about __str__? I guess I would be fine with just using the __repr__ for now. Does anybody think we need something prettier? If yes, do we want recursion in __str__ similar to what is done in __repr__? (I would say that if we want a custom __str__, then we should actually avoid recursion and go for a short representation.)

[pmli]

I would like to have a prettier __str__ for system classes, where it's easier to see the number of inputs, output, and states (and some other useful information).

[sdrave]

Ok, then I would propose to change __str__ of StationaryModel and InstationaryModel to not print the contained operators.

Can you rebase on master? Then I would make the changes to these methods.

[sdrave]

@pmli, made the changes. Please have a look.

[pmli]

@sdrave I've copied the parameter_space and solution_space parts to iosys models and did some reordering. Let me know what you think.

[sdrave]

LGTM.