[minimaxir]

That is likely a hack necessary for it to work with Python syntax. (R's ggplot2 does not require wrapping aesthetics in strings)

[_dark_matter_]

I actually usually use the aes_string command instead, which allows strings. Easy for programmatic reuse of complex ggplot commands.

[Bootvis]

Indeed, whereas function arguments in R are lazily evaluated in Python they're not.

[quantumtremor]

But is laziness that important for a graphing library where presumably you'd be graphing the function anyway? I guess there are some cases where one of the other options would disable the y-axis or something, but this seems pretty rare. Is there another reason?

[Someone]

I'm not sure whether this library supports it, but if you plot a function, a smart plotting library will evaluate the function at points that depend on the function and the resolution of your output device; you can't just evaluate the function at n points on the to be plotted range and expect to get an accurate plot.

For example, to plot sin(1/x) accurately, it must be evaluated many, many times near zero, but you do not want to do that further away from the origin, as it slows down plotting, and can produce less nice plots if you export to a vector format such as svg or postscript.

[Bootvis]

Off the top of my head:

When plotting in R the name of the names of the variables in the caller of the plot function are used as axis labels. This is pretty nifty and plotting without feels very unnatural to me (now).