Change of semantics for 'show'

[Nathann Cohen]

Hello everybody,

Just to say here that the meaning of 'show' (like in 'show(a_graph)'
or 'show(anything_else)') has been changed by #17821 [1].

'show' has been made an alias 'pretty_print', which has several
consequences for graphs (but not only). Indeed, nobody would expect
`pretty_print(a_graph)` to open a new window with a picture of the
graph: it is meant to return some short LaTeX description of the
graph.

Thus 'show', whose meaning is quite different from pretty_print, will
probably be removed in the long run as it can be confusing in some
cases.

Have fun,

Nathann

P.S.: In the latest

[1] http://trac.sagemath.org/ticket/17821

[Martin R]

Am Montag, 27. April 2015 09:07:50 UTC+2 schrieb Nathann Cohen:

Thus 'show', whose meaning is quite different from pretty_print, will

[...]

Is there any concise description (possibly proposed) of what the different output functions should do?  I know of the following functions, and have my personal expectations, but I'd be interested in others:

__repr__

print

latex

show

view

plot

ascii_art

pretty_print

Martin

[Volker Braun]

On Monday, April 27, 2015 at 4:45:42 AM UTC-4, Martin R wrote:

Is there any concise description (possibly proposed) of what the different output functions should do?  I know of the following functions, and have my personal expectations, but I'd be interested in others:

__repr__

print

We should be able to agree on these as they are part of the plain Python language.

* __repr__ (or SageObject._repr_): return a string

* print:Immediately sends the output of __repr__ to stdout

* displayhook: calls __repr__ on the value of the last statement and sends to stdout

>>>: 123

123          <-- displayhook at work

In Sage, the displayhook does more refined things like

sage: plot(sin)

Launched png viewer for Graphics object consisting of 1 graphics primitive

or displaying the graphics inline in various notebooks.

show
pretty_print

Now (#17821): show = pretty_print is like print() but with rich output, so 

sage: def f():

...:    print(123)

...:    pretty_print(plot(sin)) 

sage: f()

123

Launched png viewer for Graphics object consisting of 1 graphics primitive

Before #17821: show and pretty_print does slightly different and, at least to me, not very self-explanatory things. For example, in the SageNB notebook:

g = Graph({1:[2]})

g             #  a picture of the graph created using tkz -> pdf -> png if the "typeset" checkbox is on

show(g)   # a picture of the graph created with matplotlib

pretty_print(g)   # tkz picture again, but this time regardless of the "typeset" checkbox setting

show(WeylCharacterRing('E8'))  # a png picture containing the words "the Weyl Character Ring..."

 

latex

ascii_art

plot

latex() returns a latex code object containing code suitable for typesetting in a math environment.

 

ascii_art() returns an ascii art object that can be used as building block for building larger ascii art displays

plot() returns a graphics object that can be saved or composed into more complicate graphics

[Martin R]

Am Montag, 27. April 2015 19:18:35 UTC+2 schrieb Volker Braun:

__repr__

print

We should be able to agree on these as they are part of the plain Python language.

* __repr__ (or SageObject._repr_): return a string

* print: Immediately sends the output of __repr__ to stdout

I think it sends __str__ to stdout.

Martin

[Volker Braun]

On Monday, April 27, 2015 at 3:13:31 PM UTC-4, Martin R wrote:

* __repr__ (or SageObject._repr_): return a string

* print: Immediately sends the output of __repr__ to stdout

I think it sends __str__ to stdout.

If you define __str__ in addition to __repr__ (allowable but probably something that you should avoid if you can) then yes, print sends the output to __str__ to stdout. If you do not have a separate __str__ method then the output of __repr__ ends up being printed.

[Martin R]

I set up some examples, together with output in emacs (sage mode), except for plot.

Could you please comment, what you'd like to change?  Except for plot, the results seem relatively consistent to me, but of course, this may be because I'm using the console.

Thanks for your patience,

Martin

"""
sage: g = graphs.RandomGNP(20, 0.5)
sage: m = random_matrix(ZZ, 20)
sage: f = sin(x)
sage: D = DyckWords(20).random_element()
sage: Z = ZZ
sage: all = [g,m,f,D,Z]

# 'repr' and 'str' follow the python strangeness, as explained in http://stackoverflow.com/questions/1436703/difference-between-str-and-repr-in-python, and return a textual representation of the object.

sage: [repr(e) for e in all]
['RandomGNP(20,0.500000000000000): Graph on 20 vertices',
 '20 x 20 dense matrix over Integer Ring',
 'sin(x)',
 '[1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0]',
 'Integer Ring']

sage: [str(e) for e in all]
['RandomGNP(20,0.500000000000000)',
 '20 x 20 dense matrix over Integer Ring',
 'sin(x)',
 '((()((()())(()(()()(())))()()))())((()))',
 'Integer Ring']

sage: [ascii_art(e) for e in all]
[RandomGNP(20,0.500000000000000): Graph on 20 vertices,
 20 x 20 dense matrix over Integer Ring,
 sin(x),
                     /\                 
                /\/\/  \                
       /\/\  /\/        \               
      /    \/            \/\/\          
   /\/                        \      /\ 
  /                            \/\  /  \
 /                                \/    \,
 Integer Ring]]

sage: [latex(e) for e in all]
# summarizing :-)
[tikz code of the graph, the matrix as a latex array, \sin\left(x\right), tikz code of the DyckWord, \Bold{Z}]

sage: [view(e) for e in all]
[None, None, None, None, None]
# but opens a pdf viewer with the latex code typeset.

sage: [pretty_print(e) for e in all]
# no idea what this should do
# in sage 6.5, this seems to always hold html code containing latex code.

sage: [plot(e) for e in all]
# if I understand correctly, it should return a Graphics object, but I'm not completely sure what precisely this should contain.  Possibly:
[a drawing of the graph,
 the matrix interpreted as a contourplot???,
 a graph of the function with boundaries guessed,
 probably raise an error for the DyckWord - or should it try to draw the word as a path?,
 probably raise an error for IntegerRing]

"""

[Volker Braun]

On Tuesday, April 28, 2015 at 4:19:25 AM UTC-4, Martin R wrote:

Could you please comment, what you'd like to change? 

Thats not really the topic but why not... 

* view() should be renamed to something that is suggestive of what it actually does, maybe pdflatex(). In http://trac.sagemath.org/ticket/18116 I'm proposing latex(x).compile(), though that ticket doesn't change view()

* The commandline backend shouldn't claim to support latex output, so pretty_print(x) wouldn't output implicit latex on the commandline. If anything it is worse than ascii art and plain text in that UI. If you specifically ask for latex output via latex(x) then you will get it of course.

* Add a warning (or deprecation) in show() to use pretty_print() instead as it is more indicative of what it actually does. This is #18302

* Similar to latex(), there is a html() function. This should be changed to return the existing html container object instead of the current behavior of printing to stdout and returning the empty html container. This is #18292

 

Except for plot, the results seem relatively consistent to me, but of course, this may be because I'm using the console.

plot(x) essentially just calls x.plot(), and it'll necessarily fail if there is no graphical representation defined. I think that is unavoidable. I'd rather not have a plot(x, do_show=True) optional keyword argument as an "abbreviation" for plot(x).show(), but then there are definitely bigger fish to fry.

[Nathann Cohen]

> * view() should be renamed to something that is suggestive of what it
> actually does, maybe pdflatex().

+1

> * Add a warning (or deprecation) in show() to use pretty_print() instead as
> it is more indicative of what it actually does. This is #18302

+1

> * Similar to latex(), there is a html() function. This should be changed to
> return the existing html container object instead of the current behavior of
> printing to stdout and returning the empty html container. This is #18292

+1

Nathann

[Martin R]

Am Dienstag, 28. April 2015 16:47:24 UTC+2 schrieb Volker Braun:

Thats not really the topic but why not... 

I'm sorry about having asked an off topic question.  I did not realise that I did.
 

* view() should be renamed to something that is suggestive of what it actually does, maybe pdflatex(). In http://trac.sagemath.org/ticket/18116 I'm proposing latex(x).compile(), though that ticket doesn't change view()

OK, makes sense.
 

* The commandline backend shouldn't claim to support latex output, so pretty_print(x) wouldn't output implicit latex on the commandline. If anything it is worse than ascii art and plain text in that UI. If you specifically ask for latex output via latex(x) then you will get it of course.

* Add a warning (or deprecation) in show() to use pretty_print() instead as it is more indicative of what it actually does. This is #18302

 

* Similar to latex(), there is a html() function. This should be changed to return the existing html container object instead of the current behavior of printing to stdout and returning the empty html container. This is #18292

OK, I understand better now.  I was afraid of latex() being done away with.

Except for plot, the results seem relatively consistent to me, but of course, this may be because I'm using the console.

plot(x) essentially just calls x.plot(), and it'll necessarily fail if there is no graphical representation defined. I think that is unavoidable. I'd rather not have a plot(x, do_show=True) optional keyword argument as an "abbreviation" for plot(x).show(), but then there are definitely bigger fish to fry.

So, plot(x) would have no side effect, instead I would have to call show() on the result?  Slightly weird, but still OK for me.

[Volker Braun]

On Tuesday, April 28, 2015 at 12:35:57 PM UTC-4, Martin R wrote:

So, plot(x) would have no side effect, instead I would have to call show() on the result?  Slightly weird, but still OK for me.

Not sure I understand, so just to clarify: The current behavior is that plot() has no side effects, and p.show() has side effects but no return value.

sage: p = plot(sin)     # no side effect, returns graphics object

sage: p                    # displayhook displays graphics

def f():

    p = plot(sin)    # no output

    p                    # no output

    p.show()          # displays graphics, no return value

    pretty_print(p)  # displays graphics, no return value

    plot(sin, show=True)   # displays graphics and returns plot

I'm not a fan of the show=True (typo: not do_show) optional keyword argument, but apart from that I don't want to change anything else.

sage: plot(sin, show=True)    # two plots since we explictly display AND the display hook hits return value

[Martin R]

Am Mittwoch, 29. April 2015 02:12:50 UTC+2 schrieb Volker Braun:

On Tuesday, April 28, 2015 at 12:35:57 PM UTC-4, Martin R wrote:

So, plot(x) would have no side effect, instead I would have to call show() on the result?  Slightly weird, but still OK for me.

Not sure I understand, so just to clarify: The current behavior is that plot() has no side effects, and p.show() has side effects but no return value.

OK, my failure to understand was that I didn't know about the displayhook.  Thanks for clarifying.

But then, why doesn't

sage: graphs.PetersenGraph()

output its repr and launches a viewer instead?  Is this because, as you say above, the commandline backend claims to support latex output?

Martin

[Volker Braun]

This is http://trac.sagemath.org/ticket/18289

[Martin R]

I have read this thread, but I fail to understand the reason.  Eg., there is a commit "extrawurst for graphs".  I thought that by default all objects would display in the console their repr.  The commit seems to indicate that this doesn't work for graphs.  Why?

Martin

[Volker Braun]

On Wednesday, April 29, 2015 at 7:16:20 AM UTC-4, Martin R wrote:

I have read this thread, but I fail to understand the reason.  Eg., there is a commit "extrawurst for graphs".  I thought that by default all objects would display in the console their repr.  The commit seems to indicate that this doesn't work for graphs.  Why?

I changed graph._rich_repr_ to return graphics, so right now

sage: graphs.PetersenGraph()

Launched png viewer for Petersen graph: Graph on 10 vertices

only displays graphics (there is a message that an external viewer was launched since that may fail or take a long time). It doesn't output graph._repr_, though it uses it to construct the informational message.

In #18289 we will switch it back to graphs displaying as text on the commandline.

[Martin R]

But why do we get _rich_repr_ on the console in the first place???

Martin

[Volker Braun]

On Wednesday, April 29, 2015 at 9:52:19 AM UTC-4, Martin R wrote:

But why do we get _rich_repr_ on the console in the first place???

* display ascii art as rich representation on the console

* launch viewer when a Graphics object hits the displayhook 

[Martin R]

I don't understand this answer.  Am I the only one who doesn't get it?  If so, don't bother to explain, I'm giving up.

(I looked for _rich_repr on trac which gives me 9 tickets, none of which looked like it would explain to me when rich_repr is called, and I searched the online doc for rich_repr, which gave 0 results.)

Sorry for probably having wasted your time,

Martin

[Volker Braun]

I probably don't understand your question, so let me try a different answer in the hopes that that is what you were asking:

The _rich_repr_() method is always called by the displayhook. If the object doesn't have one (AttributeError), or if it does not return anything (i.e. returns None) then we fall back to _repr_().

[Martin R]

Oh, now that's an explanation!  So the explanation in the third post on this thread,

    displayhook: calls __repr__ on the value of the last statement and sends to stdout

was a bit misleading.  Thanks for clarifying.  (In turn, this begs the question, when is repr used for display instead of rich_repr?)

So the point really is that, at least for me personally, having rich_repr return graphics in the console (for any object, not only graphs) is very very undesirable.

(That's in the already merged ticket #17821, for the record.)

So, is this hard to fix?

Martin

[Volker Braun]

On Wednesday, April 29, 2015 at 11:37:38 PM UTC-4, Martin R wrote:

Oh, now that's an explanation!  So the explanation in the third post on this thread,
    displayhook: calls __repr__ on the value of the last statement and sends to stdout

was a bit misleading. 

Well that was about plain Python...

Thanks for clarifying.  (In turn, this begs the question, when is repr used for display instead of rich_repr?)

_repr_ is used if an object does not implement _rich_repr_ or if _rich_repr_ does not return anything.

So the point really is that, at least for me personally, having rich_repr return graphics in the console (for any object, not only graphs) is very very undesirable.

Presumably you find it desirable to display Graphics() objects (the return value of plot()) as picture, so there is that.

 

[Martin R]

Am Donnerstag, 30. April 2015 05:56:11 UTC+2 schrieb Volker Braun:

On Wednesday, April 29, 2015 at 11:37:38 PM UTC-4, Martin R wrote:

Oh, now that's an explanation!  So the explanation in the third post on this thread,
    displayhook: calls __repr__ on the value of the last statement and sends to stdout

was a bit misleading. 

Well that was about plain Python...

I'm only trying to understand.  Yes, I assume it happens that someone is using sage as a python library and then possibly only wants repr.
 

Thanks for clarifying.  (In turn, this begs the question, when is repr used for display instead of rich_repr?)

_repr_ is used if an object does not implement _rich_repr_ or if _rich_repr_ does not return anything.

OK, so if I'm not mistaken, _repr_ is for the use case just mentioned above, right?

So the point really is that, at least for me personally, having rich_repr return graphics in the console (for any object, not only graphs) is very very undesirable.

Presumably you find it desirable to display Graphics() objects (the return value of plot()) as picture, so there is that.

Of course.  Hence, _rich_repr_ (or _repr_) should not return a Graphics object, right?.

Martin

[Volker Braun]

On Thursday, April 30, 2015 at 8:19:39 AM UTC+2, Martin R wrote:

I'm only trying to understand.  Yes, I assume it happens that someone is using sage as a python library and then possibly only wants repr.

If you use Sage as a Python library then you are in control of the displayhook. The Python default which will only use __repr__. Your application can change that of course.

So the point really is that, at least for me personally, having rich_repr return graphics in the console (for any object, not only graphs) is very very undesirable.

Presumably you find it desirable to display Graphics() objects (the return value of plot()) as picture, so there is that.

Of course.  Hence, _rich_repr_ (or _repr_) should not return a Graphics object, right?.

Graphics() is the base class for (2d) graphics in Sage. It does more than just draw pictures, you can also save them in different image file formats, play with axes, etc. The _rich_repr_() method never returns Graphics, it uses its own class hierarchy to encapsulate a particular type of rich output that is supported by the backend.

sage: p = plot(sin)

sage: type(p)

<class 'sage.plot.graphics.Graphics'>

sage: p_repr = p.__repr__()

sage: type(p_repr)

<type 'str'>

sage: dm = sage.repl.rich_output.get_display_manager()

sage: p_rich_repr = p._rich_repr_(dm)

sage: type(p_rich_repr)

<class 'sage.repl.rich_output.output_graphics.OutputImagePng'>

sage: dm.preferences.graphics = 'vector'

sage: type(p._rich_repr_(dm))

<class 'sage.repl.rich_output.output_graphics.OutputImagePdf'>

sage: dm.supported_output()

frozenset({<class 'sage.repl.rich_output.output_basic.OutputPlainText'>,

           <class 'sage.repl.rich_output.output_basic.OutputAsciiArt'>,

           <class 'sage.repl.rich_output.output_basic.OutputLatex'>,

           <class 'sage.repl.rich_output.output_graphics.OutputImagePng'>,

           <class 'sage.repl.rich_output.output_graphics.OutputImageGif'>,

           <class 'sage.repl.rich_output.output_graphics.OutputImagePdf'>,

           <class 'sage.repl.rich_output.output_graphics.OutputImageDvi'>,

           <class 'sage.repl.rich_output.output_graphics3d.OutputSceneJmol'>,

           <class 'sage.repl.rich_output.output_graphics3d.OutputSceneWavefront'>})