Join me as I chat with Rich Annone and Michael Chow from Posit, where we explore the transformative
power of data tables with the Great Tables Library.
We'll cover practical applications of great tables, showcasing how thoughtful design and
advanced formatting can elevate your data presentations.
And you'll learn about innovative features like nanoplots and interactive elements, as
well as the importance of structure, format, and style in crafting tables that inspire.
Whether you're a seasoned data scientist or just starting out, this episode is packed
with valuable tips and inspiring examples to enhance your data storytelling.
This is Talk Python to Me, recorded December 19th, 2024.
Are you ready for your host, David?
You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython,
both accounts over at fosstodon.org.
And keep up with the show and listen to over nine years of episodes at talkpython.fm.
If you want to be part of our live episodes, you can find the live streams over on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming
shows.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quattro, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/posit.
P-O-S-I-T.
And it's also brought to you by us over at Talk Python Training.
Did you know that we have over 250 hours of Python courses?
Yeah, that's right.
Check them out at talkpython.fm/courses.
Hey, everyone.
Two quick announcements before we dive into great tables.
First, thanks for all your patience.
It's been a few weeks since my last episode release.
What I thought was going to be a brief winter break, pause, turned out to be longer.
I had to slow my work down recently to help my dad with some health issues.
We're getting that sorted and things are back on track with regard to the episodes.
I have six already recorded and in the queue.
Now, for some awesome news.
I have a new feature I know you're going to love for the podcast episodes.
I named it Deep Dives.
I sent an email out about this early January.
And if you're not part of the newsletter, you should be.
The idea is to add way more reference material and backstory information to each episode page
so that when you come back, you can skim through the content, pulling out important quotes,
important topics, and extra detail.
For example, on the episode I did with Carson Gross about HTMX, the deep dive starts out
with a section called what to know if you're new to Python to help you get the most out of
that specific episode.
Then it features incremental adoption and complexity budgets, HTML fragments and partial updates,
minimal JavaScript for React-like UIs, and even interesting quotes such as,
your application has a complexity budget.
Spend it efficiently by Carson.
These do not appear in your podcast player, but if you visit any episode page for episodes
that are published after October 2020, you'll find a deep dive for that show.
Now, this does not replace the links section, which still exists on the episode page and in
your podcast players.
I think it adds a ton of value.
I actually did a long write-up on this over at the Talk Python blog at talkpython.fm/blog.
Creative, I know.
So please give it a read if you want to know more.
And there's an Easter egg there as well.
There's an awesome notebook LM AI mind-blowing audio track I put in the middle that you should
check out if you're interested in that kind of thing.
It's really, really interesting.
Well done.
And we live in crazy times.
Let's just leave it there.
Check it out on the blog.
So with that, thank you.
Thank you for all the support.
And let's dive into great tables.
It's an awesome episode.
Rich, Michael, welcome to Talk Bython Me.
Great to have you two here.
Hey, thanks for having us.
Great to be here.
It's a pretty interesting topic, these tables.
You know, when I first heard about it, I was like, I was like, I, you know, it sounds
interesting, but how are we going to talk about tables on the podcast?
And you know, how, how much is it really to talk about with tables?
Turns out there's a lot.
And we're going to find a way to talk about it on the podcast.
So it's, it's a pretty deep topic.
There's so much.
You don't need two hours.
And honestly, like what you said just now is like story of my life for the past year of
like being like, what, what could tables do?
Like, yeah.
And then just being freaked out.
I mean, df.head, doesn't it?
I just solve it.
Come on.
Right.
We already got that.
We already live.
It's already so perfect.
How could we improve on that?
But yeah, I'm really excited.
Cause this is, this is me kind of like fanning over rich, but like, I think it's like the
perfect way to frame it.
Like what's up with tables.
I feel like having pulled that thread for the last year, I'm always excited to talk about
these things here because like, I don't even be able to recapture how freaked out I am by
whatever I just experienced for the past year with tables that we're just shipping away at
is really exciting.
Tables.
So you know what I would say probably my impression, which I will grant you is a pretty
fresh take on this.
It's a little bit like, oh, well, we already got Excel.
You can draw graphs with Excel or Altair, Plotly, those types of, you know, it's like, oh, wait,
there's, there's actually a lot more we could do.
That's pretty awesome.
Yeah.
We have a language too.
I feel like having discovered there's a whole vocabulary for tables, I feel like was really
enlightening.
Yeah.
I would think so.
There's, there's almost like design patterns of tables or to get into that and like structure
and some history and many things.
But as per usual, before we jump into that, let's get a little bit of background on you
guys and, you know, maybe quick introduction on the two of you, how you got motivated to
get into work with great tables and that sort of thing.
Yeah.
Rich, you want to?
Yeah.
So I'm rich.
How do you get into tables?
I mean, I had to make tons of them.
So that was sort of a necessity.
So the problem was it was annoying to do like really annoying either doing it word was
repetitive, you know, not reproducible, which kind of annoying me.
I had to redo tables all the time because we had to use a tool that was outside of like
programming.
Right.
That was like a major problem.
Actually had to retranscribe them.
There was many of them.
It was kind of blah.
So.
Right.
I swear.
Like kind of like I opened with you could, you could automate the graphs, but you couldn't
automate the tables.
Right.
Exactly.
Yes.
It was like the one last thing.
So that was like where I came from with tables.
And years later, I finally got to it.
I mean, better late than never.
Yeah.
I came in mostly to support rich.
So a lot of what I've done is work is like a data scientist in R and Python.
And I've, I've always kind of had a split and kind of split brain.
So doing a lot of data analysis in R and more engineering tasks in Python.
But I think as, as I noticed, Rich was kind of bringing this table idea to Python, I talked
with him a bit and then I peeked through the code he was working on.
And I was sort of really intrigued by how much was there.
Like, I would say the first thing that really kind of surprised me is just how much code he
had was just more than I kind of thought tables would need.
And so this is more than one's file.
I mean, come on.
Don't we just put out a header and put out the rows?
It was kind of like, there's a lot going on here for people who are not familiar with this.
Yeah.
Right.
I surprised myself too with how much I wrote.
I mean, it just kept snowballing the amount of things that had to be done.
Yeah.
I'm sure.
And we did, we both came from academics.
So we both did PhDs and I think we both produced like a decent number of tables as we did that.
But yeah, never, never quite dove as deep into them or as intricate.
Yeah.
And probably most of the time, you know, you're knocking out something in Excel or LaTeX or
something like that.
Yeah.
Once it's done, it's kind of done.
It's not, not live in the sense like every day I want a new popular view of the status or,
you know, whatever, like the dashboard sort of deal.
What were your PhDs in?
I did a chemistry of all things.
Chemistry.
I love chemistry.
Yeah.
A lot of tables.
Again, a chemistry was one of my favorite courses I ever took.
I love the two.
Yeah.
Organic was great.
Yeah.
Beautiful.
Yeah.
And I know, I know very little about chemistry.
I did cognitive psychology.
So.
Okay.
Tables in the mind or something.
I don't know.
Something like that.
Yeah, absolutely.
That's cool.
So you must have had a lot of experience with trying to present your research and your thesis
and stuff through, through tables, right?
Yeah.
Big time.
I think it counted like something like 100 tables, including that the raw data section.
So yeah, no shortage of tables there.
And a lot of it came up in presentations and stuff.
Had to remake them.
Again, no, no good tool.
So I was like, I felt like, I felt sad, but I had no time to like pursue a tool.
So I just kept going.
Yeah.
I will say, I kind of picked up too, as I started working with Rich, that he's a supreme
dabbler.
Like he has collected tables from across the world in a lot of different domains.
So that's, that's one thing that caught me too, was like, I don't doubt he produced a
lot of chemistry tables, but I was amazed that I felt like he was like a guy in an alleyway
trying to like sell me tables.
Like, oh, you like a sports table?
He's like, oh, you like basketball?
You know, you like.
Yeah.
The first, the first brackets free and then.
Yeah.
That's how it gets your hooks.
Yeah.
It kind of is like that.
Yeah.
Try to make tables possible for everybody, you know?
Yeah.
So how do we kick this off?
We got to, I just want to say to all the listeners who are not watching the YouTube live stream,
but are just listening, like most listen to the show do.
We're going to do our best to describe some of these things.
Some of them are visual, but I think we can pretty much capture the essence of them.
I will try to set up chapters and put some chapter, chapter art.
So keep an eye on your podcast player or your CarPlay view of now playing or whatever it is
that's playing the thing.
It might show, show some pictures.
We'll see what we can do with that.
But let's start off the conversation here, not on great tables exactly, but maybe just
some examples of some good, good tables to give people a sense of just, you know, what
more could you possibly do than just, you know, data frame dot header, something to that effect.
You know what I mean?
So I think it was Rich who sent this over.
Yeah.
What do you guys said?
A visualization gallery.
Yes.
From Andrew Weatherman.
And includes tables.
It has got some awesome tables.
The first thing is a table.
Yeah.
And there are 10 tutorials here.
And there are a lot of them are based on code.
A lot of them from R and stuff like that.
But which one should, which one do you think we should talk about?
Just as an introductory example, maybe.
Pretty good one is the first one.
The very first.
Like it leads with a table at the very top of the page.
It's called.
So there's conference realignment travel.
Yeah.
And right away.
So if you, yeah, if we open this table up, there is, there's pictures.
Like, so this talks about like, what is this?
A basketball college, American basketball.
Yeah.
So you've got the, the logo or the icon, you know, like the Stanford tree or the Miami, Florida
U, which is like the school colors.
And you've got little chiclets of the information.
It's, those are also embedded in sort of a heat map.
There's a lot more that there's a lot of pieces of this conveying information all at the same
time.
You want to maybe just riff on that a little bit.
Yeah.
I don't mind trying to tackle this table.
I'm just taking it in.
I think, I think it's really nice.
So this table, yeah.
Basketball realignment travel in the ACC.
So they're talking about, I guess, how hard would it be for these teams to drive to games?
And so in the table, every row is a team.
And they use like the logos next to the team name.
So it's really fast to look up.
And then in the columns are things about like, yeah, visiting arena to home arena.
So like how, how many miles would it take for this team to travel to the arenas they're going
to?
And I think that what's nice about this table is, for example, there are multiple measures
of how many miles it would take a given team to go to their visiting arenas.
So for example, on the first row, we have California.
And in columns, we have like median miles for one column and average miles for another column.
But I think what's nice about just kind of basic table structure is because these two columns,
medium miles and average miles are both kind of about a similar thing.
They're able to put a label over it called a column spanner, and they label it visiting
arena to home arena.
So they're able to do a little bit of grouping of information.
So you can see like these two measures, these two columns are related to each other.
And then I like...
Yeah.
Michael, that's a super interesting point that I think is very well represented in gray tables.
And that is almost multi-dimensional data.
Yeah.
Right.
And so, like you say, it's got three columns here, median miles, average miles, and then
this other geographic center column.
But above those, there's like groupings.
Like these two columns speak to how far is the visiting arena from home versus the other one
is just sort of an extra description, right?
So you're able to say, here's this axis of information, but you can really group them together
and think of them as something else it's representing almost or something combined, like a projection.
I don't know, something like this.
Yeah, totally.
And I think the interesting thing too is like in databases or in data analysis, this kind
of structure is there, but it's not visual oftentimes.
Like someone might have a table and they might have two columns, one for like median miles,
average miles, but they might actually like, oftentimes people in the name will put the grouping.
So like if those two columns are related, they might say like visiting, you know, prefix it
with like visiting underscore.
And so it's interesting, like tables, raw data tables often have these hierarchies, but
this kind of lets you pull it out visually.
So like the human eye can quickly kind of group things.
And then to your point about multi-dimensional, that is kind of like one of the big benefits
of a table is that this, for example, this table has three columns related to miles and
a plot.
You could show that in a plot.
You could plot two columns against each other with a scatter plot and maybe use the third
column another way through like color or size.
But at that point, you've kind of maxed out the plot.
There's not a lot more you can do.
A table, you can just keep adding columns and they don't even have to be numeric or like
kind of on the same scale.
You could add like all kinds of information in columns and keep going.
And I think to your point of it being multi-dimensional, that's one kind of nice thing table support is
many measures on the columns.
Yeah, absolutely.
This portion of Talk Python to Me is brought to you by Posit, the makers of Shiny, formerly
RStudio and especially Shiny for Python.
Let me ask you a question.
Are you building awesome things?
Of course you are.
You're a developer or data scientist.
That's what we do.
And you should check out Posit Connect.
Posit Connect is a way for you to publish, share and deploy all the data products that you're
building using Python.
People ask me the same question all the time.
Michael, I have some cool data science project or notebook that I built.
How do I share it with my users, stakeholders, teammates?
Do I need to learn FastAPI or Flask or maybe Vue or React.js?
Hold on now.
Those are cool technologies and I'm sure you'd benefit from them, but maybe stay focused on
the data project.
Let Posit Connect handle that side of things.
With Posit Connect, you can rapidly and securely deploy the things you build in Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Ports, Dashboards.
And APIs.
Posit Connect supports all of them.
And Posit Connect comes with all the bells and whistles to satisfy IT and other enterprise
requirements.
Make deployment the easiest step in your workflow with Posit Connect.
For a limited time, you can try Posit Connect for free for three months by going to talkpython.fm
slash posit.
That's talkpython.fm/P-O-S-I-T.
The link is in your podcast player show notes.
Thank you to the team at Posit for supporting Talk Python.
Out of the audience.
Carol points out that the ACC used to be mostly Southern based, but now they span the whole
U.S.
But what you can see from this chart is all, or this table rather, that all the Southeast
based universities have a much easier time.
The color of their little chiclets of distance are all very light colored.
Whereas if you look at all the California West Coast, it's like distance across the U.S.
is your average distance you travel to each game.
And it's pretty wild.
You could probably put in things like, what is the team's typical winning outcome based by distance?
If it has to play a team that is twice as far away, are the players more likely to show up tired
and not quite be able to play as good?
And then that might somehow affect the rankings just based where you physically are located.
Yeah.
That's what makes this a good table because it basically tries to get that slice of the
data, right?
That one view of the data and present it so nicely.
And then it causes you to think those things, right?
To explore further.
Yeah, exactly.
I don't know what I would have been able to do before.
Yeah.
But looking at the colors, you're like, oh, California, as in Berkeley and Stanford and those
types of schools, they're much darker versus Louisville, which is not very much, or Duke
or all these other teams.
And then you start to realize, oh, maybe distance does play an important role.
It just jumps right out, even though this is not a thing that I think about or care very
much about on a lot of levels.
But, you know.
Yeah.
And even to Michael's point, that last column is like a total qualitative measure or not
qualitative, but it's basically just like a label rather than like a number, essentially.
So it's much easier.
In a plot, I don't even know how you would do that.
You just, I guess.
But here you can.
Just to describe the last column is, you're talking about like furthest.
So the last column shows what's the furthest team from.
So each row is a team.
The last column is essentially what's the furthest team from you.
And they're able to just put a logo in to get a quick kind of snapshot.
And you can play on that extra column.
Basically, if you were to play an away game at that team, that's the worst travel for you.
But at least measured by distance.
It's not like by time.
And like if you're taking a flight, you could have three connections to a small town versus
a direct one that's far away.
Right.
Like there's different metrics you might apply to what defines furthest.
But that's a neat idea.
Yeah.
It's interesting though.
Right.
Because they didn't put bother to like rewrite the name of that team.
They just economize the space and just like threw it in in case you're interested.
It's like.
Yeah.
And the value for that column is not the name of the school.
It's the school logo.
Yeah.
And I will say, I can't believe that the year is 2024 and we just had a five minute
discussion on the design of a single, I didn't imagine myself being here a year ago, but it's
really.
This is the problem.
I'm telling about it to me.
Yeah.
Amazing.
I feel like Edward Tuftay must come into existence a lot for you guys.
But it kind of goes to show tables can be cool, right?
Like we're actually talking about this table and it's interesting.
And it's good to look at.
And I'm like, I don't know.
Like this is like a leisure thing.
I'm not compelled to look at this.
Yeah.
I'm looking at this for fun.
And like, it actually is okay.
I enjoy looking at this table.
Yeah.
I'll pull one more down.
I have no idea what I'm going to be getting here, but let's do Spotify listening.
How long do I listen to my top artists before skipping?
Yeah.
I think to your Tufty point too, this is a good example that you can have, you can have a
little bar chart inside your table.
So like this, this table, how long do I listen to my top artists before skipping?
Each row is an artist with some information about them.
And then the big thing it sounds like is this average stream duration column, which has a
bar of how long people stream them on average, maybe before skipping.
Yeah.
I love your point about Tufty.
Like this idea that you can encode a small graph, like visual, like a bar is very, I think
Tufty, like with sparklines and things like that.
Tables can have a really compact representation that bring in some of the value of charts.
But also it's like, it's like three quarters table, one quarter chart.
And that's kind of common.
For those out there who don't are not steeped in Edward Tufty sort of lore.
He's a guy who thinks very deeply about data presentation, not necessarily tables or graphs or
whatever, but just, I have a bunch of kind of data stats based information.
And how could I possibly present this in the way that conveys the most information easiest?
So on.
So yeah, he's got, he's got some great books, some great presentations out there.
That's why I brought it up.
Cause it's his whole career is about how do you present data basically.
Right.
And if you guys should add to that, what do you think?
I think there is a, I don't have it on hand.
There is a quote, I think from Tufty, I don't want to butcher about, there is some analysis
he's done of tables of like, like your entry architecture or something, which is essentially
like the structure of the table where you enter it as a user.
And then like how you read usually determines your like orientation.
So like, if you're, if you're reading left to right, there's usually like the table structure
has like an entry point.
And then if you're reading left to right, it kind of determines how you're going to go through.
He's done some thinking about tables as sort of architectures, I think, but I haven't, I haven't
gone too deep into it.
Me neither.
But I guess that informs like things like sorting that we saw in other tables.
Like there's a dominant sort, the most important things are at the top, maybe least important,
but there's, there's definitely some sort of like, you know, like conscious sorting.
And like, it's obvious what it is and it's just to sort of serve a purpose.
Yeah.
There's probably an art to finding the thing that attracts your attention first.
And so then as you progress through looking at it, you can do so in a deterministic, purposeful
way rather than just, you know, you land anywhere and you start looking around visually.
Yeah.
It's wild because like it is such a, such a creative act making a table.
It seems weird to say it.
It's not just results.
You just slap down.
You have to envision yourself in the, the viewer's shoes and like how to, how they would
ingest or like digest information in the most easiest manner possible with all sorts of like
little affordances, like the way you format things, space in between columns, all sorts
of wild, little tiny details.
They all really combine to like make something really good or to make the table shine.
I guess you can say.
Yeah.
Yeah, absolutely.
I want to come back to this one about the, the listening.
Um, and I'll, I'll link to all these in the show notes, of course, here we've got the average
stream duration and it's represented by little bars in the table itself, which we've already
talked about, which is awesome.
And the values are things like 87%, 80%, 84%, whatever that little section is fraught with
possible misrepresentation.
So if that was just a number and it was average seconds, well, if you listen to say the scorpions
or some of the older rock bands or iron maiden, I don't know where they have songs that are
like seven or eight minutes long versus more modern songs that are, it may be two and a half
minutes long.
And it said, Hey, look, I only listened to these like two and a half minutes, but I listened
to the scorpions for three minutes.
That must be the winner, right?
Like, no, you're not even listening close to the same amount.
So putting numbers even there, even before you would normalize them, right?
Just put them as a percent of, of that, as like the total average of the song or something.
There's a lot to think about with these things and that can kind of go away with these graphs,
right?
You don't have to worry about that.
You're like, Oh, you don't have to worry about how long is their average song.
You can see, you know, just how long did I listen to their stuff?
That's kind of cool.
Yeah.
It's really cool.
And it's a great use of space too, right?
Like horizontal bar plot.
I mean, these are like rows, which are not that high, but you still fit a plot in.
We don't have that many choices, but, horizontal bar plot.
Yeah.
It could be just a couple of pixels high and you can still see, see that kind of information
super well.
Exactly.
As long as you use enough color or whatever.
All right.
Well, let's talk about great tables.
So I feel like we probably have set the stage well enough for, for people to go, okay,
maybe there's, maybe there's something here rather than just, you know, header rows and columns.
So tell us about great tables.
When did it come into existence?
Why do you guys build it?
What is it?
Yeah.
Yeah, sure.
So I actually started from an R program or package a long time ago back in 2018.
Um, and like, there was like essentially like a list of projects that were sort of like,
I'm not being handled at our, at then our studio now posit and tables was there.
It was like, Oh, this seems like such an obvious one.
I will take that.
I will work on that.
And I have an interest in that.
I'm going to do it.
Nobody else did it.
It was on that list for years.
And it kind of begs the question, like why?
Because tables are such omnipresent, you know, way of presenting data.
I see it like in, I don't know, like journal articles, like half the things are tables, half
things are plots.
Um, and they're, you know, everywhere else.
So like, yeah, there should be this thing.
So I decided to just get going on that.
And, as, as Michael said, like, it's a lot of code and like, I didn't envision
it would take that much code.
I thought it'd be rather simple working with HTML table and then, you know, expanding towards
other types of like table outputs, like a PDF, you know, word and stuff like that.
Uh, but I thought, you know, those would be bite-sized little things as it turns out tables
run pretty deep.
Um, and I really only found that out when looking at, I was doing some like literature review
and I found that 1949 census manual, it's like the review of tabular, presentation.
Yeah.
It's a great PDF that lives on the internet.
It's always there.
Thanks.
Whoever put that up.
What year is this from?
1949.
49.
Yeah.
It's, it's like a janky scanned in thing.
Yeah.
But that's only a line, but it's, you know, this is like hundreds of pages of table stuff.
It's both a style guide for the census at the time.
And also just like an amazing reference for anything in tables and even just presenting
data.
Like they, they go so deep on the smallest little things.
It's incredible.
Yeah.
They sketch things out.
They give things names.
That was super important because otherwise he'd just be saying that area on the top left,
whatever that is.
It's good to have names.
It's like design patterns for.
Exactly.
Yes.
And this is what was needed.
And I'm pretty thankful I found this.
Otherwise we'd have to make it up, but this seems like as close to a standard as we'll
ever find on this sort of thing on making tables.
Right.
So in 1942, we have the formal table and its major parts continued, you know?
Yeah.
And there's so much good text.
Like it's expertly written.
Um, this stuff, I mean, of course these are tables in print and of course we have the web.
So that changes things a little bit, but you'd be kind of surprised how, how, you know,
still relevant these recommendations are.
They teach you to be economical with how much data you put on, how much, basically the
Tufti thing, how much ink are you going to like spend on a visualization?
And, it just carries it through to all the different parts, which is, you know, amazing.
And we took a lot of that and applied to here as best as we could, you know, with some
more modern things as well, but, yeah, of course, but it's yeah, pretty much a very
useful reference, like the foundational reference for this.
So right on the great tables page, you've got the components of a table.
Yeah.
You want to give us a sense of what's beyond header rows and columns?
Yeah.
Michael, would you?
Sure.
Yeah.
I think so.
I mean, I think even just the very first thing at the top, this table header with a title and
a subtitle that's like, that, that seems like a really simple thing, but I think that it's
easy to overlook.
Um, like a lot of people think of a table as just the like data and maybe some labels.
But if you think about like the information hierarchy and someone who has maybe 10 seconds,
five seconds to figure out what's going on.
As it turns out, the title is probably the most, one of the most important parts because it tells
them in two seconds, what should I expect from this thing?
So like, if you send to your boss a table, if you had to do one thing, you should probably
put a title on it so that they know what you're sending to them.
And I think, so that's like, maybe a silly thing.
Maybe it feels like table stakes, but I think like the title and the subtitle are small elements
that really kind of, if you're thinking of a table as communication, you, you wouldn't
write an article without a title.
Um, so this really is just.
Probably wouldn't put a graph up without a title.
Right.
Yeah.
Right.
So it's kind of bringing tables up to the standard of other communications.
Yeah.
And then I think, the other thing I really like is these are really simple elements,
but these footnotes on the bottom and source notes, this idea that if you just create a
spot for your like references, it's a lot easier to get into the habit of, of referencing
where things came from.
So like we have some table examples in our gallery and they, in their footnotes, they often
say where, we got them from.
And it's just so, so helpful having that like hook that you can hang into to quickly, like
as a quick reminder that if you, like, if you make it easy to put your references and footnotes,
you know, you just can make a habit of it.
So those are kind of funny.
Those are like the bookends of a table, but I, I really appreciate that they're there to
emphasize how critical they are.
If tables are a form of, communication.
Yeah.
The one that stood out to me and I called out at the first table we talked about was the
spanner label.
That kind of says these three columns are kind of in some category together.
Yeah.
The hierarchy is pretty important.
It lets you sort of like, Oh yeah, I care about this package of, or this set of columns,
or maybe I don't, maybe I care about these ones over here.
You just quickly get oriented to like the columns that, you know, are more useful.
And also it allows you to do that thing that Michael mentioned before.
You don't have to like have tons of like label on the below columns, like on one label or
tons of text on one label.
You can split it up between like spanner and then like the things that it's associated to,
you know, the columns.
So you might have things like, some type of measure and then like the units for the
column labels, for instance.
Yeah.
In our basketball example, it could be distance from visiting arena that could just have average
or miles from visiting arena and then just average and median.
And that's all it has to say, but you wouldn't have average and median.
And that's called them like, unless it was really, really clear, but in a complicated
thing, it wouldn't make sense to just have those two words like average or what, you know?
Yeah.
As part of that visualization, thoughtful design is about, allows you to be creative and also
thoughtful for the user or the reader, I should say.
I think it helps too.
Cause a lot of tables I've seen go big on columns.
There's like quite a few, there can be tons of columns.
And so I think when you have like, let's say you have a dozen columns, if you have like
two or three spanners over them, it feels easier.
It feels like closer to a table with three columns in a sense.
When you get started, you kind of know what you're getting into.
So you can kind of ease into it.
Yeah.
You can kind of zoom in by picking a spanner and then paying attention to those pieces or
something.
Yeah.
Yeah, totally.
As well.
Having these tools at your disposal as well.
Also kind of like lets you be, I guess, creative, but also it gives you options to, to explore
different ways of creating a table.
If you didn't have like the ability to put a spanner, say in this program, this, this Python
library, you'd have to think of other ways you'd have to, it, it basically changes your
whole presentation, not having options to do so.
Right.
You'd want to try to leverage color maybe to try to infer their group somehow, but then
yeah, it's still, it's incomplete.
Yeah.
For sure.
Yeah.
So a non out in the audience asks, like there's a lot, R has lots of great examples, but I've
struggled since it's not equivalent in Python.
Let me suggest.
Oh yeah.
I kind of feel like, like great tables is the entry point for a lot of that.
Right.
What do you think?
Yeah.
I think too, maybe something rich you can hit on is there's a lot to appreciate from the
history of R. Like it's really surprising to people how hard people have gone on tables
in R.
Yeah.
And some of everything leading up to rich working on GT and R tables in R in 2018.
There's actually like a 20 year history leading into that.
Yeah.
That maybe rich.
You can talk a bit about the kind of.
Yeah.
Before you guys just jump in real quick.
You guys both are, we didn't catch this in the introduction, but you're both working at
Posit, the company that created Shiny.
It was an absolute leader in R and now has Shiny for Python and all those kinds of things.
So just adding some background.
Yeah.
History for everyone.
Okay.
Go ahead.
Yeah.
So basically R goes back probably about as far as Python, 90s or so.
But R seemed to have a head start on tables.
I mean, as far back as 2000, they had a LaTeX sort of table generating package.
And then in the intervening years, the decades since up to now, they've had upwards of eight
to 10 table packages.
I think had to do with the fact that data frames are just like, you know, as part of the language.
So it just made sense to make a table.
And also they just had, I guess, a lot of tooling for creating PDFs, especially for like
package like references.
So basically R has tons of like examples, vignettes and things like that.
Maybe not so much on the Python side.
We're trying to get that in.
Although I've been maximal on the table examples for the R version of this, which is called GT.
Haven't quite got there yet on the Python side.
So if you're seeing less examples, then you might see on the R side, make sure that they
are coming soon.
Yeah.
Still working on it.
Yeah.
So let's talk about, let's talk about the Python side about what is my data journey to
get something into great tables and then maybe what comes out of great tables.
So it starts with sounds like data frame libraries.
What ones are supported?
How's that work?
What's the most ideal one?
Yeah.
So we, we support out of the gate pandas and polars.
And we have, we've made this into lean pretty hard on polars in our examples, just because
it has some kind of special moves that work really well with great tables.
So for example, selectors and stuff, right?
Yeah.
Selectors.
So that really was eyeopening to us.
And I think the polars team a little bit, I think they hadn't, I think great tables was
one of the first packages that went really hard in integrating with polar selectors as part
of our API.
So there are like, if you want to set a spanner label, so you want to set a label over some
columns, you can use polar selectors to do that in great tables.
And that's a really nice, that's, that's what we do all the time.
And it's really convenient.
I think that that was kind of an early use of an external package for the polars team
using their selectors and stuff.
So we, we had a lot of communication with them about it early on, but I would say, so it takes
a pandas or a polars data frame.
And we've leaned pretty hard into polars just because of some of these really nice affordances.
Yeah.
If you go to the get started guide, you'll see it inside of selecting table parts and then
like selecting columns.
I believe we have this little sidebar, which sections up the getting started.
Oh boy.
Yeah.
Okay.
Getting started.
Oh, if you go to the very bottom on the sidebar.
So scroll down.
Yeah.
That.
Column selection.
So sorry.
There we go.
Yeah.
There's a whole using polar selectors section.
Yeah.
Here we go.
Yeah.
So that's just an example of dropping polar selectors into the great table method to move
certain columns to the beginning of the table.
Yeah.
Or you might do another example where you choose a number of columns to put a spanner over
top of, and they might be named in a systematic way, which is like the advantage here.
And you can do it for pandas as well.
Just not with selectors.
You just use lambdas and such to have similar functionality.
Interesting.
Okay.
Yeah.
So yeah.
Pandas are polar's polar's has some really nice benefits like selectors.
And then it also, it's used quite a bit whenever we style a table.
We often use polar's expressions to kind of target the areas to style.
So if you want to choose like for this column, make the maximum value of the column yellow.
It's really easy with polar's expressions to say, you know, when this column is equal to
the max value in itself.
I see.
Yeah.
That's really cool.
And because then you don't have to figure out what the max is and then try to come up
with a gradient range of it.
You just put it into little bins or whatever.
Yeah.
Yeah, exactly.
Totally.
One thing I just noticed that's pretty sweet about this actually is you, you already talked
about the sources and the references and things like that.
Yeah.
But I just noticed that you have markdown support for your references.
Yeah.
That's a good one.
Because like sometimes you want to bold italicize things, maybe make a list within your footer,
your source notes.
Yeah, sure.
I mean, even in the official way you're supposed to reference things, there's stuff that's supposed
to be italicized and stuff that's not right.
Exactly.
Yeah.
So you want these tables to be useful for like a wide range of people.
And if they didn't have that, I don't know what they would do.
They'd just use HTML, I guess, and try their best with tags.
But this is just an easy, obvious way to make it simple.
Yeah, that's really great.
So we start with some data.
We load it ideally into polars, it sounds like, but pandas is also supported.
And then you kind of visually, I say visually, the indentation of the way the code looks somewhat
represents the structure of the table.
A little Flutter or HTML-esque in that sense.
Yeah.
Yeah, totally.
I think we think a lot of it about in terms of three main activities, structure, format,
and style, and we've tried to make the method names match up a bit.
So everything starting with tab is basically about structuring the table.
So that's those big pieces in the diagram we looked at, whether it's setting the title with
tab title or tab header or setting footnotes.
Those are all structure activities.
So they all start with tab.
And then there's this just incredible bucket of formatters.
Rich really went ham on formatting methods.
So it's everything starting with FMT.
This is like, yeah.
Yeah.
This is like, maybe you want to format the number of decimal places, but Rich has gone even further
to like, maybe you want to put like a country flag in your table.
Rich has got you.
He wanted it to be easy for country flags.
And I'm here for it.
Yeah.
So those little graphical elements are amazing for quickly conveying information.
Kind of like the logo of the various universities that you would see on SportsCenter or whatever.
You're like, yeah, that's what I'm used to looking at.
Yeah.
That's right.
You just use format image for that.
And you just, yeah.
Give it an image on disk or wherever.
And it gets in there.
Yeah.
And I was kind of confused why I was adding so many formatters at first.
But I feel like the thing that really clicked for me is that if you think about, so if you
go, actually, if you go up to the very top and then into the reference on the top bar, that
will have lots of formatters under, yeah, format.
Yeah.
They're just listed out.
So what clicked for me is that spreadsheet users.
So people in Excel making a table are really used to tons of convenient things like formatting
dates, formatting.
Right.
You highlight a column, you press currency, then you press the move, the decimal point, two points
to the left to drop the portion, the partial ones and all that.
Yeah.
So there's a world like the engineer in me thought like, ooh, I kind of wish this wasn't
our job to do all this formatting.
But I think Rich very intuitively picked up on like, well, if people use Excel for tables,
I think you have to give them a compelling reason to be able to do it all in Python, or
they're not going to really want to make the jump.
And so I think having all these formatters is just a way of bringing that kind of nuts
aspect of Excel into great tables.
And some of this stuff is tough and fiddly if you do it yourself.
I'm not just talking about simple format.
Like strings.
Yeah.
I'm talking about.
Yeah.
Can I do like a colon and then a comma and then a 0.2 and we're done?
Yeah.
First you got to do that.
And then like, there might be some other weird things.
So we try to like make it super simple with just some simple options, some arguments and
you're pretty much there.
Yeah.
One thing I'll maybe give a shout out.
I know you talked about it, PyCon, was if you've got a bunch of numbers, like let's say
it's currency.
You might want to format that using like, if it's over a million, 1.2 M.
But if it's only 120,000, you might want to say 120 K.
Yeah.
Right.
Something where it's.
Yeah.
You don't need sort of an abbreviator.
Yeah.
It's, it's also useful if you have like tons and tons of numbers, like a wall of numbers,
you're running out of space.
So you just need to compactly.
And like the small figures don't really mean much.
Like you just want broad strokes.
Like it just can be the compact thing.
It's great.
And it works really well for like things where you don't need to have that much precision.
Based on the.
Yeah.
You also seem to have taken a pragmatic approach where it's not like, well, you're not, we're
not going to let you mix units in a column.
Right.
If it's, it's not, you know, kilometers and meters, like it's all kilometers.
It's all meters.
Take it or leave it.
You know?
Yeah.
I think.
Freedom, baby.
That's what you want.
You can like, you can target.
So we have like a column targeting system, but you can also like sort of like subset,
like what rows you want.
So that's the way.
So basically you can like format different ways down the column if you so choose to, which
makes it more flexible.
Yeah.
I think, I think it goes back to, to Excel and, you know, Excel is just a big lump of
clay.
You can just carve out your table however you want.
And it, it does like do formatting, but it doesn't prescribe.
Yeah.
Like you said, it doesn't constrain you to have to like do it for a whole column.
And I think that's like, we're endlessly surprised by the types of tables people create and the
things they communicate.
And in a way it's like leaving room for surprise that people are so creative.
You, you want some constraints, but you kind of also want to let them surprise you with things
you wouldn't think of, but that end up being really useful.
And I, I don't doubt someone's there like mixing all kinds of things in ways I wouldn't
imagine, but end up kind of working out.
I think it was like in our table contests where I was like first surprised.
Basically we, we, we throw together table contests at, at posit.
It's such a nerdy thing, but like people submit tables and they get judged on them.
Like they, they get prizes.
Everyone's a winner.
Rich is a very kind judge to be sure.
It's like everybody wins in Rich's house.
Yeah.
But they're so good.
Like when I see his tables, I'm like, I never even thought of that.
Like that, that could be done.
You'd want to do that.
And I actually like it.
Like, yeah, it's actually inspiring every time.
It's gotta be pretty hard to build a framework around such a visual flexibility, you know?
Yeah.
But still have some kind of something prescriptive, right?
Yeah.
I guess the trick is just like have easy conveniences just to do broad swaths of formatting and styling,
but also make it granular.
Give people power, I guess you could say with, along with simplicity.
Yeah.
So tell people about these contests.
If somebody wants to try, try their hand at great tables and submitting something, you know,
I think we're even in the advent of code time.
And I guess we just had the hour of code stuff, but there's a lot of these things where people
are trying, I just need some examples to play with, to try to, to learn a thing.
Right?
Yeah.
So we do it in the summer, so not wintertime, which is actually good for submissions.
So it's still coming up.
Yeah.
And we give a generous amount of time, I think like two or three months, if I remember correctly.
But yeah, we just, we just made the call, say, submit your table.
We have a nice form and people submit them.
And we sometimes get up to 50, not 80 entries.
It's like, we get quite a few.
And then we, we do the tough job of, you know, having a number of judges and just, you know,
multiple judge grading of the tables.
And we had so many that we had to split them up into categories, right?
Because we were going to celebrate all these different types of tables and different domains
of, you know, have typically different types of tables.
And so it just makes sense to break it up in that way.
Yeah.
And I do, if I had to give advice, it's like much more free form than a lot of the advent
of code.
There's no, because there's no target or even necessarily starting point.
It could be really hard for some people, I think, to get started or figure out like, what
could I do with this?
But I think if I had to give any advice, I think looking through the past entries is so
helpful, like scanning past entries and even choosing some that inspire you.
And then whether it's, whether you take data similar to those and maybe try to do something
related or go in like a similar direction and look for new data.
I think the existing entries are really, really inspiring.
I, if I had to-
Get that creative juices flowing, right?
Like, oh, I didn't even think you could go down that direction.
Let's try that with my data.
Yeah.
Because I think if you start with just a blank page and you're kind of new, even to
great tables, it can be hard to know where to go.
But once you start looking at entries, I think you get a feel for all the kinds of things you
can do with it.
Oh, that sounds great.
How important is it that you have interesting data to start with?
Like, hey, let's grab the data that they use to image the first black hole, try to make
a cool picture out of, you know, table picture out of that.
That's a great question.
I think it really hits on one of the neat things about these contests is that you don't
have to have interesting data at all.
Actually, one category of entry is kind of zany.
It's like recreating something that exists in, say, like great tables or some other library.
Like Rich and I were talking recently about GitHub issues.
So like GitHub issues are a really interesting example of a table because they're a table that
software developers work with nonstop.
Like I'm all in those tables all day.
And it's like an interesting entry would just be to recreate that.
Like if you recreated GitHub issues in a table and it looked really spot on, that's like its
own kind of special accomplishment.
Like, and I think those entries are fun to see like someone recreate an existing thing in great tables or something else.
So that, so yeah, to your point on data, I think you could start with even not having to find interesting data, but find an interesting table out in the wild and just try to recreate it.
Yeah.
So I don't know if this has anything to do with your contest or not, but let me suggest an interesting angle to this in terms of like competitions for this or just broadly for people who are listening.
One is I've got really interesting data.
I have a story to tell and let me try to like really inspire you with my custom story.
You know, if you look at racing, like specifically auto racing, we've got F1 where everyone designs their own car.
There are some rules, but they kind of, they all have a thousand or 500 people that work on it.
Then you've got spec racing series, like Indy, where everyone has the same car, the same engine, or there's two choices, whatever, same thing.
And then they compete.
So it would be interesting to have a category that is like, this is the data.
You have to work with this, but tell a story.
Like who could tell the story the most interesting with like the same data, which sounds a little bit Kaggle-like, I suppose.
Yeah.
Or Tidy.
Have you seen Tidy Tuesday?
Tidy Tuesday?
Yeah.
Tidy Tuesday.
I think it's exactly what you're describing.
Every Tuesday they release a data set.
Yeah.
And then people, oh, wow.
It's very, there's a GitHub repo somewhere where they.
Yeah.
If you search for Tidy Tuesday GitHub, you'll definitely find it.
But essentially, yeah, it's just like data and you're, you left your own devices about how to present it.
It could be tables, plots, anything.
Yeah.
I'm surprised the big Tidy Tuesdays, it's kind of a tricky one.
There's a, I think there's a Tidy Tuesday organization, but yeah, same data and yeah, people analyze it and then they share it out on socials.
Yeah.
So you get to, I think exactly to your point, like you start from the same place and you see where people get to.
And I know like one R user, Dave Robinson for a long time, would screencast himself live analyzing for an hour.
Oh, wow.
Okay.
So he plots like, what does it look like for someone to analyze the data?
And I think that's, that's a fun dimension too, that you don't see often.
Like just how does it unfold?
Like, right.
What point does he plot?
And when does he go backwards?
It's like the Bob Ross of, of tables, you know, like the happy little trees come first and then this and that, oh, that's how you make that picture.
Okay.
Right.
It does take time.
Yeah.
I mean, like just yesterday I was making new examples.
I'm not surprised how long it takes to make a compelling example for a table.
It's like, thanks time.
You have to mess with the data.
Yeah.
And I will say this, this coffee table example that Marco pointed out.
So the, the coffee table example for people listening is, it's an example table we created where every row is a like coffee device.
So it's the idea of this table is for like a fictional coffee device shop and every row is a coffee device.
And then there are columns on like, oh, how many did we sell?
How much profit did we make?
And then there's a nice little, there's a column that's little bar charts, that show the monthly sales broken down.
Um, try hovering over one of those bars.
Yeah.
So this is one of the things I wanted to make sure that we got a chance to talk about, because this is, we've talked about having images in here, which is great.
And the, what is this thing called?
That this group spanner, I can only think splitter.
I'm like, no, it's not the spanners and the colors and stuff there, but then you have what in the framework referred to as nano plots.
Yeah.
Right.
So that we already saw the bar graph, but that was just an example, but here we've got like a little bar chart.
And Rich, as you point out, as I interact with it, it's, it's like a little plotly type thing.
Like if I had, if I were real young and my eyes were real good, I could read that.
Well, they're very small, but you have very low space.
So like, I mean, they're nano size.
That's why they're nano size.
They're not even micro plots.
They're just nano plots.
Exactly.
But yeah.
That's all we got here.
They're meant for HTML and meant to be lightweight, slightly interactive.
Just to give you a little something, you know, to, to mouse over and to, to drill down.
Massively important because it shows you it's, I had Stephanie, Stephanie Molin on a little
while ago and she has this project that sort of, if you want the same information about the
statistical summary of some set of data, like the standard distribution, the mean, the max,
the min, and it could be like one little blob or she has this thing, it'll animate it into
like a kangaroo or something.
And then it's, it's got all the same information.
You have the same problem with tables here, right?
Like the, the total amount sold, the percent sold.
But if you look at the, the nano plots, some of them are really spotty and some of them are
pretty much flat and that it tells you a whole nother dimension.
That's kind of, this is kind of what I was getting at.
Like you could make this multi-dimensional and that that's another piece of communication
that isn't just, you know, rows and columns.
Yeah.
It's a nice conversation too, because each of those bars could variable be a column, right?
I can have like a January column all the way up to.
Yeah, exactly.
Yeah.
So it just shrinks it down.
And it's useful.
So you're having a table and a plot and you got to like jump back and forth.
Like it's, it emerges these two ideas in a pretty cool way.
Yeah.
Sort of explain the difference between tables and plots.
I like too, that with the nano plots, like these little bar charts, maybe their job, like
in a lot of tables, their job is to focus you onto a row.
Like if you notice that pattern's interesting, it pulls you onto that record, that row.
And then that lets you visit other columns to see like supplemental information that maybe
suggests what could be happening or like gives you information to look up more as you're doing
an analysis.
So it's kind of a neat, like visual pattern as a way to index onto interesting cases.
And then table columns have the power to give you more information about these cases.
Yeah, that's cool.
It seems like because you can put markdown into these pieces as well, you could have them
maybe jump to the full size plot or something more, more rich as you want to kind of expand
a row or something.
Yeah, totally.
I think there are interactive table libraries too.
So one we have ported to Python recently is called Reactable.
So we made a port called ReactablePy that it offers expanding tables.
So if you're interested in a row, you can click it to expand down, say like more information
or even a lot of like detail and description.
But I think to your point, yeah, that's a really neat possibility of being able to like
click and either be taken somewhere or have the table like open up.
And yeah, that would be cool to have an inline capability.
Yeah, I do.
I do want to note one thing about this table that I think about a lot is we I'm so glad that
Marco brought up.
It was useful because we spent a long time.
We spent, I think, a couple of weeks creating this table.
And I talk about this with open source developers sometimes that I think about this, like how
long we spent on this table, because this table's job was to illustrate like structuring, formatting
and styling in like what should be like your first encounter with great tables.
And so we really, in a sense, as we created this table, we were on the hunt for a table that
both introduced people to a range of activities, like looked nice, but also had code that we
could explain.
And I it's like so hard.
I feel like as open source maintainers sometimes to find that like right example, like compelling
shows off like a range of activities, but also is approachable.
And I do remember like Marco, one thing that opened my eyes is he, I think he shared this
table on LinkedIn once, but he shortened it to like three or four rows.
And that I'm always really interested in seeing those types of activities because I think that
post really took off.
And it, I don't know, it always like teaches me the power and the value of really like getting
an example down and getting it.
So it's interesting, but also like short and compact is like such a art that some people
are so good at.
Yeah.
It's, it's very cool.
We don't have much time left.
So I want to focus on the last bit of this journey that data goes through great tables.
And that is what happens, where does it go at the end?
You know, like what can I export?
Yeah.
So we talked about HTML and this interactive bit, but what are the different places that you
could send this to?
Well, I think the big ones are notebook.
You're just iterating through some data and you want a table.
Maybe you want to present that as well.
So notebook is like a really good example.
So maybe you put that actually just in a cell and just as part of the notebook, it just runs
there.
Yeah.
That's right.
And another one is just like, you want it somewhere else and maybe you want it in a presentation.
You want a graphic.
So we have a facility for that.
It's the save method.
We just like you get a image file or even a PDF from the table.
And sometimes you just want to take that HTML and run with it somewhere else, maybe embedded somewhere,
maybe put it inside of an email.
So we have an as raw HTML method, which gives you an HTML string that you can just like pop
in somewhere else.
Nice.
And does that just give you like the worst possible HTML in the sense that like everything that
has a color has a style set straight on it and stuff like that?
You have two different stages.
You can have it like the style block, sort of like as a one div with the table and the
style block embedded.
Or you can have all the styles in line, which is a new feature, which is actually useful for
emails.
Yeah, exactly.
Because as much as you want to write nice stuff, we can't have nice things because a lot of
the email clients forbid you from putting styles in there.
It's most notably Gmail.
If you put a style, even a solid style block, it'll just throw it away.
So you've got to just jam it onto everything.
If that thing can be bold, it's in a span and it has, you know, style, font weight bold
on it, you know?
When I first learned of that like years ago, because I'm in the email game as well.
I was like, really?
How does this exist in this year?
But it does.
It still exists because of certain clients.
So, yeah, but luckily there's lots of like great, and we have it here too, but there's
lots of people who have developed libraries to inline CSS into tags.
Yeah.
That's the right purpose.
I guess one more output, sorry, is a little attack, right?
Yeah.
As the final destination.
Yeah.
That's a new thing.
So if you're running a paper, you want a table in it, we now have some way to get the
table in attack.
If you want your academic paper or your dissertation to have it, like, in it goes.
Yeah.
Sorry, Michael, what were you going to say?
Oh, no, I think one interesting thing too, is I think .show, we have a really great contributor,
Ju Young, that prompted this.
I think because he was teaching a workshop to vision impaired, like data scientists.
And so .show is handy to be able to call .show and have it open a browser with the table, I
think was like really useful.
And that was so helpful to have as a issue.
And I think that contribution to GreatTable is really huge.
Yeah.
Because then a screen reader could read it.
Exactly.
Yeah.
Facility for that.
But also it's kind of disappointing to work in the console and not have anything being shown.
It's like, what?
Yeah.
So that's really good.
And I see Carol noted Quarto, which is actually the whole GreatTable's website is built with
Quarto.
And that's a nice format.
So it uses a file called a QMD, which is a lot like Markdown, but it can run the code.
And Quarto is really convenient for building things like websites or HTML reports.
And it's also developed by Posit.
But we, yeah, we end up putting tables a lot in like Quarto documents or the like GreatTables
website.
Yeah.
Through Quarto.
And maybe he's too bashful to mention it, but he developed like the library Quarto doc,
which makes this site possible and makes those tables rendered.
Oh, that's awesome.
Like Michael.
That is.
Oh, yeah.
I guess for context.
So like some tools like IBIS, their API docs and the GreatTables docs.
Yeah.
We just created a small tool called Quarto doc to let them put their like API references in
these websites so they can use Quarto.
Yeah.
That's excellent.
Yeah.
Very, very cool.
All right.
Well, I think we're pretty much out of time.
I guess give people a sense of where you're going, like roadmap type stuff.
Is anything they should be looking out for?
Yeah.
I think we want to port quite a bit more from the R program over to GreatTables.
That includes things like merging, concatenating values from different columns into single columns.
Things like adding footnotes to tables.
So the footer is more put to better use.
And more refinements to formatters and additional formatters.
There's quite a few more things to go.
But even right now, it's pretty mature.
But there's probably things people will ask for that I haven't thought of.
So that's the nature of the game.
I think Anon is asking for Excel.
We'll put Excel in there, you know?
Yeah.
Yeah, I'll get to that.
The snake will eat its own tail.
Excel's a big one.
We'll put GreatTables in Excel so you can just go all the way to the bottom, wherever that is.
Well, I think one other thing to note is extensions that in R, tons of people have extended GT, the GreatTables for R.
And tons of helper packages.
Like if putting a bar in your table is something you want to do, there are a lot of these inside extra helper packages.
And so I think one nice thing would be we want to kind of create a example helper package just to give a feel for how people in Python could also create this kind of stuff for GreatTables.
If you want to extend like, yeah, if you wanted to create your own little bar charts in GreatTables, it seems like people have done a lot of that in R.
And so it'd be cool to try to foster that kind of ecosystem and extension.
Absolutely.
Yeah, that's awesome.
All right.
Well, I'm going to leave everybody with one parting thought, and then I'll let you guys give a final call to action.
You're looking at some of these examples, especially those 10 ones that you called out, Rich, that I'll link in the show notes.
If you're doing a presentation to your company on your blog as a data scientist or just generally, it's so easy, I think, to just have the tables and then maybe somewhere you have a picture or something.
But if you put something together like that, that will get people's attention straight away, right?
It's just really another level of production.
And the fact that you do it with Python means it's reproducible.
You do it once and off it goes.
Like that's pretty excellent.
So if that sounds like something you all do, you should check out Great Tables.
It looks pretty excellent.
All right.
Michael, give a final call to action.
People wanting to get started with Great Tables, what do you tell them?
You know what?
Visit Great Tables, probably on GitHub.
Check out the examples.
I think the examples are such a helpful way to get started.
And then if you get any questions at all, we have a Discord or we love hearing from people in the issues.
You know, we want to hear from you.
Read it all.
We consider it pretty, you know, pretty carefully.
Not carefully, but we want to do people.
Like style pays.
Like you just got to churn out those beautiful tables.
You know, there's no other choice.
That's right.
I think also once you set up one of them, if you kind of do similar types of tables, like you can reuse that code in a lot of ways.
So unlike doing a design or something.
All right, Rich, final word.
Final word.
Contribute.
Like if you want more of a call to action, just get into the site, discuss things with us.
Even if your idea is like way in left field, we'll probably consider it and maybe even do it.
That's how eager we are to please when it comes to tables.
Awesome.
So PRs are accepted.
PRs, anything.
Issues, complaints, whatever.
Beautiful.
All right.
Thanks for coming on the show, guys.
Yeah.
Thanks for having us.
Yeah.
Congrats on the project.
See you later.
See you.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free.
By going to talkpython.fm/posit.
P-O-S-I-T.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct
RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to
subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Bye.
you
Thank you.