Consider a possible "methods-based" interface.

[iangow]

I have heard it said that plotnine is "not Pythonic". I explore this claim here and I conclude that perhaps the claim is strongest with the need to either say from plotnine import * (or at least from plotnine import [lots of things]) or make the code ugly with import plotnine as p9 and then p9.ggplot(p9.aes()) + p9.geom() + ....

With the help of Codex, I made a feature branch that provides a more "methods-based" interface on a fork here. The code changes seem quite non-invasive.

I think the "methods-based" code looks quite Pythonic. I also made a demo site here and everything seems to "just work" so far.

[iangow]

Perhaps some place out of the way like plotnine.objects (mirroring Seaborn's objects interface) might be a natural place for this. Basically plotnine.objects could just add_fluent_methods(ggplot) and nothing else would change (though maybe tidier if re-exports things from the "main" plotnine, so you could do from plotnine.objects import ggplot, element_text or whatever).

The more I look at Seaborn/Matplotlib, the more impressive plotnine seems. Someone directed me to this today: https://stackoverflow.com/questions/4700614/how-to-put-the-legend-outside-the-plot

I'm not sure I want to get a PhD in Matplotlib!

[TyberiusPrime]

I believe this out of scope for plotnine, which explicitly mirrors the ggplot2 api.

That being said, I also like my plotnine fluent, so I wrote
dppd_plotnine which wraps p9 objects upon request.

It has one more big change, "color" is an aes, while "_color" is a non mapped argument. I find this natural, but it's a step further away from ggplot. See https://dppd-plotnine.readthedocs.io/en/latest/aes.html

[iangow]

I believe this out of scope for plotnine, which explicitly mirrors the ggplot2 api.

If so, this does mean that plotnine feels a bit like a plotting package for R users who miss ggplot2 (and it's hard to blame them) rather than a thorough implementation in idiomatic Python of Hadley's interpretation of the Grammar of Graphics. Using from plotnine import * and then doing everything with functions is common R style, but it's not very "Pythonic".

Yes, you can do import plotnine as p9 and then p9.ggplot(p9.aes()) + p9.geom() + .... But relative to a methods-based approach, you're adding needless + p9. characters where . would suffice.

It seems there should be an excellent Python implementation of the Grammar of Graphics that doesn't carry the baggage that comes from it happening to have been first implemented in R. Seaborn objects is definitely not that implementation. (There's too many plotting packages to try them all.) But plotnine really almost is.

That being said, I also like my plotnine fluent, so I wrote dppd_plotnine which wraps p9 objects upon request.

I can't really do that for my purpose. I'm translating a book that has code for Python users. So "use my custom plotting package" doesn't work. But I don't think I want to add from plotnine import * to every chapter. So for now I'm grappling with the awfulness of Seaborn/Matplotlib (it is very common for four lines of ggplot2 code to become 20 lines with Seaborn/Matplotlib, even though the plots look worse).

It has one more big change, "color" is an aes, while "_color" is a non mapped argument. I find this natural, but it's a step further away from ggplot. See https://dppd-plotnine.readthedocs.io/en/latest/aes.html

[TyberiusPrime]

Such 'code examples' are one of the big advantages of plotnine mirroring ggplot2 so closely - the R code transliterates with almost no changes, you can apply the ggplot2 book in python without hassle, etc.

Remember, it is not just an API, it's a whole grammar of graph(s|ics).

It's so entrenched in the visualization space, there's even a 2nd python implementation (lets-plot) that also follows the grammar as proposed.

But I'm only a very minor contributor and this isn't my show - if @has2k1 wants to support a fluent API, I certainly won't mind.

[iangow]

Such 'code examples' are one of the big advantages of plotnine mirroring ggplot2 so closely - the R code transliterates with almost no changes, you can apply the ggplot2 book in python without hassle, etc.

But offering a fluent API doesn't change anything about that. Just as the Seaborn objects interface doesn't change anything about how existing Seaborn code works.

Remember, it is not just an API, it's a whole grammar of graph(s|ics).

Yes, ggplot2 is an implementation of the grammar of graphics implemented in an R way (i.e., functions, not methods). plotnine is an an implementation of the grammar of graphics implemented in an R way in Python. Don't get me wrong, what plotnine is able to do with Matplotlib (in a way that Seaborn really doesn't) is simply amazing. I just think it would appeal to more people if it offered an additional, more 'Pythonic' API. (Also, I don't think overloading + is in any way 'not Pythonic', but having to import many methods [often from plotnine import *] arguably is.)

It's so entrenched in the visualization space, there's even a 2nd python implementation (lets-plot) that also follows the grammar as proposed.

I don't think anything is "entrenched" in Python visualisation space in the way ggplot2 is. If I decided to learn data science in R, there's a very good chance that I'm going to be nudged to ggplot2. But coming to Python over the last couple of months, I've seen materials using Matplotlib, Seaborn, Seaborn object, Altair, plotly, hvplot, plotnine, lets-plot, … And also the claim from experience Python users that "plotnine is 'not Pythonic'".

But I'm only a very minor contributor and this isn't my show - if @has2k1 wants to support a fluent API, I certainly won't mind.

Indeed. I am not a contributor in any way, but I think having something more 'Pythonic' would help attract more users, etc.

[iangow]

Interestingly, great_tables (another Posit-supported Python port from R) seems to run with a more methods-based interface than the original R version (which, idiomatically for R, emphasizes pipes and functions).

[iangow]

Maybe something like this would make more sense if there were an import plotnine.polars that registered a DataFrame namespace (a bit like what import hvplot.polars does). That namespace plotnine or ggplot could then be used as df.ggplot.plot() or even df.ggplot(). In that context, a more methods-oriented approach seems quite natural. I did a quick demo here.

[iangow]

@has2k1 Thanks for adding this to "Discussion" … I'm still working on it (i.e., testing it) a bit.

[iangow]

@has2k1 In addition to the demo mentioned above, I also use plotnine_polars in several of the "chapters" of the "Polar Coordinates with plotnine" demo here. I also use it throughout this book.

Some things I've wondered about as I've been using plotnine_polars over recent weeks:

1. Would .set_theme() and set_guides() make more sense than the current .add_theme() and .add_guides()? I had to choose something to avoid conflicts with the existing attributes .theme and .guides.
2. Does it make sense to have .aes(). I have mostly been importing aes() and using it as a function, as .aes() seems a bit of a departure from the Grammar of Graphics ideas. Of course, allowing mapping to take a mapping (e.g., mapping={'x': 'x', 'y': 'y'}) would seem quite natural … this could call aes() behind the scenes.

[has2k1]

1. add_theme and add_guides would make more sense because themes and guides get merged. Though I think I am going to make .theme and .guides private and that would free up that namespace.
2. I think it makes sense to import aes. Even with .aes(...) you still need to have .geom_*(aes(...)).

[has2k1]

This topic has come up before, #24.

[iangow]

1. add_theme and add_guides would make more sense because themes and guides get merged. Though I think I am going to make .theme and .guides private and that would free up that namespace.
2. I think it makes sense to import aes. Even with .aes(...) you still need to have .geom_*(aes(...)).

I think .aes().geom_*() happens to work in the current implementation of "plotnine_polars", but I think importing aes() makes more sense simply because there's too much to reason about (e.g., the order of operation) if there are multiple .aes() calls.

In my current usage, I have a lot of import plotnine_polars as p9 (so I can do p9.element_text() and such like) and from plotnine_polars import aes so I can use bare aes(). I believe in either one of these plotnine_polars could be replaced by plotnine without effect; so long as one of them imports from plotnine_polars, all works (i.e., ggplot namespace for Polars data frames and all functions attached as methods).

So maybe import plotnine.polars could work.

A nice thing is that it's all dynamic, so with the coord_polars()/coord_radial() version of Plotnine I have, I can do .coord_radial() with no change to plotnine_polars.

(Of course, it seems that the Polars focus is perhaps unnecessary in the long run. For example, hvPlot offers import hvplot.pandas and maybe that import plotnine.pandas could use similar ideas as plotnine_polars to implement a "fluent" API that works for pandas too. Looking at the examples in the hvPlot documentation, it seems that the idea of method chains is less relevant to the hvPlot API than it might be for Plotnine.)

[iangow]

This topic has come up before, #24.

Yes, that discussion even has the context-manager-namespace idea I tried for a while.

[beskep]

I completely agree with the OP.

Following up on #24, I have written a quick workaround script that generates a type stub to support method chaining.

plotnine_method.py

from functools import wraps

import plotnine
from plotnine import aes

__all__ = ("aes", "GGPlot")


class GGPlot(plotnine.ggplot):
    def __getattr__(self, attr):
        plotnine_func = getattr(plotnine, attr)

        @wraps(plotnine_func)
        def f(*args, **kwargs):
            return self + plotnine_func(*args, **kwargs)

        return f

    def __dir__(self):
        return plotnine.__all__

generate_stub.py

from pathlib import Path

import plotnine

STUB = """from typing import Any, Self

import plotnine
from plotnine import aes

__all__ = ("aes", "GGPlot")

class GGPlot(plotnine.ggplot):"""
METHOD = "    def {}(self, *args: Any, **kwargs: Any) -> Self: ..."

EXCLUDE = {"ggplot", "ggsave", "save_as_pdf_pages", "aes"}

if __name__ == "__main__":
    methods = [METHOD.format(it) for it in plotnine.__all__ if it not in EXCLUDE]
    stub = "\n".join([STUB, *methods])

    Path("plotnine_method.pyi").write_text(stub)

plotnine_method.pyi

from typing import Any, Self

import plotnine
from plotnine import aes

__all__ = ("aes", "GGPlot")

class GGPlot(plotnine.ggplot):
    def after_scale(self, *args: Any, **kwargs: Any) -> Self: ...
    def after_stat(self, *args: Any, **kwargs: Any) -> Self: ...
    (...)

I don't think the EXCLUDE is exhaustive and argument type hints are missing, but the IDE can autocomplete the method chain.