Jules Walzer-Goldfeld https://juleswg.me/blog.html quarto-1.8.26 Mon, 04 Aug 2025 00:00:00 GMT A Great Summer of Great Tables Jules Walzer-Goldfeld https://juleswg.me/posts/Posit-Internship-Reflection/ I spent the summer working for Posit (formerly known as RStudio), and I loved it. I was on the tinytools squad, as an intern for Great Tables, the Python port of {gt} in R. My team was responsible for many of the major ports from Posit’s R packages to Python. They are awesome – this is certainly an incomplete list, but they’ve created the Python versions of {ggplot2}, {pointblank}, {scales}, {forcats}, {dplyr}, and {reactable}, to name a few.

My summer consisted of:

  • Building and packaging a Python library (gt-extras)
  • Contributing fixes and features upstream to Great Tables
  • Presenting and promoting the open source work
  • Pairing with mentors and collaborating across Posit

What I Did

The technical work at first largely consisted of work on my own package, an addition to the Great Tables ecosystem by way of extension. Then I was able to contribute directly to Great Tables as well, which was very satisfying. I also had the unexpected (and welcome) task of presenting and promoting my work to the open‑source community.

I also got to meet tons of folks from the wider Posit community, thanks to internal weekly matchmaking, fun talks/hangouts (and even an in-person meetup). I’ve met so many wonderful people over the past few months that I couldn’t possibly list them all here. Suffice to say that from intern hangouts to coffee chats with Posit developers in Europe, to career advice with former python open source team members, to data science talks, the remote world of my internship has not been all too remote.

gt-extras

If you’re here I’ll assume you know about the gt-extras package, or at the very least you know who I am, so I’ll avoid the shameless plug. The overwhelming majority of my work this summer has entailed a port of the {gtExtras} R package to Python, a task that was made more complex and interesting because of the underlying differences between the R and Python versions of Great Tables.

The core tasks of the gt-extras library are to:

  1. make existing features of Great Tables easier to use
  2. add in-cell plotting
  3. compose styles to replicate the themes of famous publications
  4. execute simple html and post-processing steps

Rich Iannone (one of my great mentors) got me started with the package structure, since he had already written a minimal version with one theme. That class of functions turned out to be the most bang for my buck – take the exact styling options researched and implemented by Thomas Mock in {gtExtras}, and with minimal syntax changes I had finished the themes!

But it wasn’t all copy and paste. In fact, after that, just about every function had a pretty critical deviation from the R version. The underlying dataframe in the Python package is different from R, and gtExtras had access to ggplot2, two elements that were inaccessible to me. Since we wanted to keep dependencies light, I did all of the data wrangling and graphics myself.

Michael Chow (my other great mentor) pointed me towards Narwhals (a library meant for handling different dataframe libraries). Both he and Rich encouraged me to try out different approaches to plotting, and while they could have easily told me “do it this way,” I am very grateful that I was trusted enough to make those decisions and discoveries myself.

Over the first couple of weeks, I met with both daily, and later we made longer term targets and paired for the more critical decisions. One of which was the first external contribution into my package, which was a delight to see. For the most part, I was given low-level autonomy over implementation choices, and reserved pairing for decisions like how to approach building plots or how to unify competing underlying dataframes (looking at you, Narwhals 👀). The independence was freeing, as it helped me learn what I could do myself, even when at first it felt like a good thing to ask for help on (like designing the documentation website).

Okay, fine – I can’t help but show off some of the cool things it can do. We can see a summary of the 2011 NFL season, my favorite being the winloss charts, primarily because of how much winning my New York Giants did that season.

A mega-example built with the gt-extras library

Great Tables

The very first PR I made to Great Tables was an entirely new feature, to rotate column labels 90 degrees. I don’t think I realized it at the time, but the workflow of that task was exactly how I approached the functions in gt-extras. Namely, I had to write a function, write a docstring with an example, add it to the documentation, and then write tests. This last part kind of grew on me, even though I’d embarrassingly never really done it before.

It didn’t stop there – as I progressed through styling and coloring functions, I uncovered little improvements I wanted to make to Great Tables. The bonus side effect of spending all those hours extending Great Tables is that I became perhaps the most frequent user (and tester) of the package. Eventually, I got to a point where I was fluent enough with Great Tables source code, and tacked some larger features and known bugs. So a number of my own GitHub issues (and my subsequent PRs) made their way into the repository:

  • a grand 😉 new feature
  • a collection of many different fixes to old group bugs
  • a row striping indexing bug with grouped data
  • a data coloring palette bug
  • an improvement to autocoloring the text of striped rows
  • an improvement to autocoloring in semi-transparent elements

Package Promotion

It seems obvious now, but I had never thought about what happens to a package after we write it. It’s a good thing I had Michael and Rich pushing me through this step because, had it been up to me, the world would never have learned about this package. Talking about the package doesn’t come easily to me, especially when it’s to an audience of more than just my roommate, but it really helped that the team gave me the first boost (and it certainly didn’t hurt to have the Posit organization promoting it too).

And selfishly I must admit the effect of broadcasting the package far and wide is rewarding. Seeing the package featured on a blog post, or used in someone’s repository will make my day. Because it’s so cool to know the design choices I stayed awake thinking about were (possibly) appreciated by a fellow data enthusiast.

What I Learned

This summer touched on so many aspects of open source code, from the technical to the collaborative. I learned how to take an idea and turn it into a fully functioning Python package, and I gained hands-on experience with the whole development workflow. Beyond the code itself, I also learned the importance of communicating my work, whether through documentation, blog posts, or presentations.

Package Development

Before this summer, I had no idea what really went into making a Python package from scratch. I learned how to set everything up, from the folder structure, to setup files, to GitHub actions and beyond. I got comfortable with things like versioning, documentation, and publishing to PyPI. Now packaging up code feels way less mysterious and way more doable.

The open process taught me to write code that is readable and maintainable, not just functional. I also gained a deeper appreciation for documentation, not just as a reference, but as a way to welcome new users and contributors.

Development Organization

With a little shame, I must admit I never knew how to use a branch. That’s an exaggeration. I knew what a branch was, and I knew to make one so I didn’t have to commit to the main branch. The shameful part is once I had a branch, all the new code went into that. (🙈 Don’t look at the repository for this website). And then one day, when I felt like there was probably too much code I hadn’t committed to the main branch, I’d merge it and ta-da, surely that was good enough… right? Fortunately, I learned about how to separate code into isolated pieces, to then merge code in a way that keeps the project organized and maintainable.

With even more shame, I have to admit I didn’t know how to write a suite of tests. Again, I knew what tests were supposed to do, but the concept seemed like something meant for more professional environments, never for code that I worked on. Until my work became code that other people could theoretically rely on – then I knew it had to be dependable. So from snapshot tests, to checking for the presence of css and html content, future changes and dependency upgrades can be relied on not to break the package.

I’m not claiming to be a pro, but thanks to Rich and Michael’s mentoring, I am now much better at adhering to these practices than I used to be.

Writing things like this!

Whether it’s a blog post for me (this one!), a blog post for Great Tables or a blog post for the entirety of Posit, I have had no shortage of opportunities to talk about my work. As you might guess, this doesn’t come naturally to me, but it’s yet another skill I’ve gotten to practice and hone in my summer at Posit.

In every instance (yes, even the slides), I’ve presented my musings using Quarto markdown. I promise I’m not getting paid to say this, but having never used Quarto before this summer, I can confidently say I can’t imagine a life without it. Life with Quarto was especially easy when the team that maintains it was part of the organization I worked for :) which I’ll definitely miss. Instead, I guess you’ll find me lurking in GitHub issues.

What’s Next (It’s not over yet)

At the time of publication, I still have a few weeks remaining in my time at Posit. Big things are still planned, from more features in gt-extras, to upgrades for Great Tables. Stick around here or give gt-extras a star and follow along with my work there.

]]> Python Great Tables Posit https://juleswg.me/posts/Posit-Internship-Reflection/ Mon, 04 Aug 2025 00:00:00 GMT Adding Plots to Great Tables Jules Walzer-Goldfeld and Michael Chow https://juleswg.me/posts/Posit-adding-plots-to-great-tables/ While working on gt-extras, I’ve been exploring how to add small plots to Great Tables. These can go by many names, like spark lines, nanoplots, and so on. In this post, I’ll look at three approaches I tried: adding plots with plotnine, svg.py, or adding HTML directly. In the first two cases, the plots are SVGs, while the latter entails a collection of composed HTML div elements.

Here are the pieces I’ll cover:

  • svg.py: creating your own tiny chart directly for a row.
  • direct HTML: adding HTML divs directly.
  • plotnine: adding a full, stripped-down chart to a row.

In the end, it’s often simplest to use svg.py, since you can create basic charts with minimal overhead. Building elements with HTML has even less overhead, but it is also slightly less user-friendly. At the other end of the spectrum, as your charts become more complex, using existing packages like the more exhaustive plotnine is a good alternative.

Animal Legs Plot
Ostrich 2 2
Spider 8 8
Lion 4 4

Here is the final result:

Code 
import polars as pl
from great_tables import GT
from svg import SVG, Rect, Line

df = pl.DataFrame({"Animal": ["Ostrich", "Spider", "Lion"], "Legs": [2, 8, 4], "Plot": [2, 8, 4]})

width = 50
height = 30
max_legs_value = df["Legs"].max()


def create_plot_svg_py(val: int) -> str:
    canvas = SVG(
        width=width,
        height=height,
        elements=[
            Rect(
                x=0,
                y=height / 4,
                width=width * (val / max_legs_value),
                height=height / 2,
                fill="blue",
            ),
            Line(x1=0, x2=0, y1=0, y2=height, stroke="black"),
        ],
    )

    html = f"<div>{canvas}</div>"
    return html


GT(df).fmt(fns=create_plot_svg_py, columns=["Plot"])
Animal Legs Plot
Ostrich 2
Spider 8
Lion 4

Setup

Here is the code to start:

import polars as pl
from great_tables import GT

df = pl.DataFrame(
    {
        "Animal": ["Ostrich", "Spider", "Lion"],
        "Legs": [2, 8, 4],
        "Plot": [2, 8, 4],
    }
)

gt = GT(df)

The Binding Component: GT.fmt()

Let’s take advantage of the fmt() method to apply a plotting function that formats our row values into plots. To see how we might use fmt(), we first need to define a formatting function to apply to each cell in a column. It will take as input the value in the cell, and should return whatever you want in that cell. Before plotting, let’s imagine we wanted to replace the number with a tally of the number of legs:

def create_leg_tally(value: int) -> str:
    return "|" * value


gt.fmt(fns=create_leg_tally, columns="Plot")
Animal Legs Plot
Ostrich 2 ||
Spider 8 ||||||||
Lion 4 ||||

A Lightweight Approach: Svg.py

Now we can apply that same logic to making our plots. Let’s start with the function that will eventually be passed into fmt():

from svg import SVG, Rect, Line

height = 30
width = 50


def create_plot_svg_py(val: int) -> str:
    canvas = SVG(
        width=width,
        height=height,
        elements=[
            Rect(
                x=0,
                y=height / 4,
                width=width * (val / max_legs_value),
                height=height / 2,
                fill="blue",
            ),
            Line(x1=0, x2=0, y1=0, y2=height, stroke="black"),
        ],
    )

    html = f"<div>{canvas}</div>"
    return html

Here you get to call fmt() to modify the column you want to apply the plotting function to.

gt.fmt(fns=create_plot_svg_py, columns="Plot")
Animal Legs Plot
Ostrich 2
Spider 8
Lion 4

This was very direct, we didn’t have save to a buffer or import heavy duty plotting functions. We built the string with the help of svg.py and were able to insert into the table. See the string below:

'<div><svg xmlns="http://www.w3.org/2000/svg" width="50" height="30"><rect x="0" y="7.5" width="25.0" height="15.0" fill="blue"/><line stroke="black" x1="0" y1="0" x2="0" y2="30"/></svg></div>'

Even in its outputted form the string is still easily readable, which is another upside of using an SVG generation package.

Extreme Minimalism: Adding HTML directly

In the previous section, note that svg.py simply generated a string of HTML. You can do the same thing directly.

def create_plot_html(val: int) -> str:
    bar_element = f"""
    <div style="position: absolute;
                width: {width * val / max_legs_value}px;
                height: {height / 2}px;
                background-color: purple;
                margin-top: {height / 4}px;
    "></div>"""

    line_element = """
    <div style="position: absolute;
                top: 0;
                bottom: 0;
                width: 1px;
                background-color: black;
    "></div>"""

    html = f"""
    <div style="position: relative; width: {width}px; height: {height}px;">
        {bar_element}
        {line_element}
    </div>
    """

    return html

Now that we’ve defined our create_plot_* formatting function, the call to fmt() is identical to the one above.

gt.fmt(fns=create_plot_html, columns="Plot")
Animal Legs Plot
Ostrich 2
Spider 8
Lion 4

At first glance, encoding HTML in multi-line strings may not be aesthetically pleasing, nor is it particularly more lightweight than svg.py. Still, it provides a good alternative if you are like me and insist on being as close to the output as possible. Separately, I have found the inclusion of text to be simpler with HTML on account of the default text handling behavior that comes along with it.

A Comprehensive Package: Plotnine

from io import StringIO
from plotnine import (
    ggplot,
    aes,
    coord_flip,
    geom_col,
    scale_y_continuous,
    scale_x_continuous,
    theme_void,
    geom_hline,
)

max_legs_value = df["Legs"].max()


def create_plot_plotnine(val: int) -> str:
    plot = (
        ggplot()
        + aes(x=1, y=val)
        + geom_col(width=0.5, fill="green", show_legend=False)
        + scale_y_continuous(limits=(0, max_legs_value))
        + scale_x_continuous(limits=(0.5, 1.5))
        + coord_flip()
        + theme_void()
        + geom_hline(yintercept=0)
    )

    buf = StringIO()
    plot.save(buf, format="svg", width=0.5, height=0.3, verbose=False)
    svg_content = buf.getvalue()
    buf.close()

    html = f"<div>{svg_content}</div>"
    return html


# This might be familiar by now
gt.fmt(fns=create_plot_plotnine, columns="Plot")
Animal Legs Plot
Ostrich 2
2025-11-11T11:52:41.639051 image/svg+xml Matplotlib v3.9.4, https://matplotlib.org/
Spider 8
2025-11-11T11:52:41.695352 image/svg+xml Matplotlib v3.9.4, https://matplotlib.org/
Lion 4
2025-11-11T11:52:41.749777 image/svg+xml Matplotlib v3.9.4, https://matplotlib.org/

Nice! But that was a sizable chunk of code just to create plots comprised of one bar each. If you’re like me, you’ll find it’s not at all trivial to do, especially without experience using the plotting package.

However, this isn’t the only graphic you might want to have on display – when you come across a use case that necessitates more detailed plots, a comprehensive plotting package like plotnine could very well be your best bet. Imagine we are passing in a list of tuples and want to generate a scatterplot, writing all of those as svg.py elements or direct HTML would be quite cumbersome.

Conclusion

How you choose to add plots to Great Tables is up to you. In writing graphical plotting functions for gt-extras, I’ve personally turned towards an HTML-only approach that I’ve felt comfortable with in other settings. With that said, I do believe converting table values to graphic output is a task best done with a little bit of help (whether it be svg-py or another plotting package will depend on how detailed your plots are).

The choice ultimately depends on your specific needs: simplicity and directness, versus abstraction and power. By understanding the trade-offs, you will be able to tailor your approach to the needs of your project.

]]> Python Great Tables Posit https://juleswg.me/posts/Posit-adding-plots-to-great-tables/ Thu, 03 Jul 2025 00:00:00 GMT