Pandas is at the core of virtually all data science done in Python.
That is, virtually all data science.
Since its beginning, Pandas has been based upon NumPy.
But changes are afoot to update those internals, and you can now optionally use PyArrow.
PyArrow comes with a ton of benefits, including its columnar format, which makes answering analytical questions faster, support for a range of high-performance file formats, inter-machine data streaming, faster file I.O., and more.
Reuven Lerner is here to give us the lowdown on the PyArrow revolution.
This is Talk Python To Me, episode 503, recorded April 8th, 2025.
Are you ready for your host, please?
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 brought to you by NordLayer. NordLayer is a toggle-ready network security platform built for modern businesses. It combines VPN, access control, and threat protection in one easy-use platform. Visit talkpython.fm/nordlayer and remember to use the code talkpython-10. And it's brought to you by Auth0. Auth0 is an easy-to-implement adaptable authentication and authorization platform. Think easy user login, social sign-on, multi-factor authentication and robust role-based access control. With over 30 SDKs and quick starts, Auth0 scales with your product at every stage. Get 25,000 monthly active users for free at talkpython.fm/auth0. Reuven, welcome back to Talk Python To Me. Awesome to have you here.
Thank you so much. Delightful to be here with you.
Yes, we're coming up on conference season and I saw you doing conference things. So bit of a conversation about what you're going to be covering at PyCon.
Absolutely.
Yeah. I'm really, I mean, I love conferences. I love seeing people. I definitely got to the point where they're like conference friends who I see every year and we can sort of catch up and hang out. It's just like a fun, fun experience. I always tell anyone who can like go to conferences. It's a great place to learn, but it's also just a great place to have fun.
I agree with that. I also think it's a great way to connect more deeply with programming and technology and libraries and all that kind of stuff. It's real easy for, I think, for a lot of folks for this to feel like a set of tutorials and documentation, right? And then you get there and you're like, oh, all these people are doing it and they're excited. And there's the person that made that one. And, you know, like to swim in those waters, it's different.
I also feel like it's kind of sad, but I mean, I go to all these companies and I get a feeling that for many people who are in programming nowadays, it's kind of lost its fun and its creativity and so it's very nice to be in a community where because open source everyone's there because they want to be there and because they are excited about it and you can sort of like you know recharge your excitement batteries as it were and realize oh there's more to this than just the drudgery of day-to-day and meetings and filling my corporate goals uh it's nice it's fun
it is and you know speaking of just swimming in the waters and what is water right that famous quote you talked about how it's so much fun because of open source and things like that like I hadn't thought about that for a little while.
Like, you know, when I work on stuff, I can just do whatever I want.
If I want to share it, I can share it.
I don't have to share it.
Use whatever libraries that might be coming along that look promising.
There's not
a corporate mandate like we're going to have these features for our library in seven months.
And because the customer demand asked for this and we're going to put this thing in to promote our cloud or our other thing or whatever, right?
There's a lot of people out there writing code with a lot less flexibility.
Oh, my God.
Yes.
And I seem to see more such people each year.
And I also feel like I always say, like, I have this sort of dual flexibility that I feel very privileged to have that, A, I'm a freelancer, I'm independent, and B, I work in open source.
So I can say such and such is dumb or such and such is bad.
And people have like a normal job, as it were, have to sort of say, well, like, this is our product and it's great.
Or at least they have to say it's the outside world.
Whereas day to day, they're just going to meetings saying, how can we convince people that this is great?
So, yeah, yeah, it's a nice way to escape that corporate golden handcuffs.
Oh, I'm making it sound really terrible.
For all of you listening, I'm happy you have good jobs.
I really am.
Unfortunately, I'm afraid people might start having to appreciate their jobs a little bit more.
Things are looking a little hectic out there.
I don't want to go into that, but one little side diversion before we dive into the main topic.
You go into all these big companies.
What's the LLM AI story for those?
Is
it different
than people on the outside who can just YOLO around the tools however they want?
Or what's it like?
So every company is different.
Every company is asking that question, right?
And no one has an answer.
I think a growing number of companies are assuming that their people will use LLMs of some sort.
Copilot's been around for a while.
People are using that.
A year ago, I have one big client where they said, no, of course we would never use ChatGPT.
And just a few weeks ago, I said, so, like, what's the story?
Oh, yeah, we're definitely using some things.
We'll get back to you on one.
So
it's been increasingly
integrated just because, especially, you know, if you're a senior developer, these LLMs really help you just zoom along.
The junior ones, it's sort of like a little iffier, but everyone at least has to answer the question, what are you doing with these?
And I think it's increasingly integrated into their workflow.
I don't think anyone knows what is the right way to do it.
I do think that these companies that are talking about, well, we're not going to hire any developers this coming year because instead we're just going to use LLMs, that's just nuts.
I think they're asking for trouble there.
And in general, I tell people, don't have the LLMs write code for you.
Have it help you strategize.
Have it go over your code.
Have it help you learn things.
But somewhere, somehow, they're going to have LLM-generated code that no one's going to look at.
And I don't like that idea so much, at least for now.
Interesting.
I would not trust 100% LLM written code.
Not even necessarily because I think LLMs are bad at writing code.
I'm stunned at how good they are at it.
But they write the code that you ask them to write.
Even if they get it 100% right, they write what you ask them to write.
And it's like, I'm just seeing the office space guy like, I'm good with customers.
I talk to the customers.
What would you say you do here, Bob?
Like
that guy?
I mean, you know, and you've got to give the specifications to the AI really, really well.
There
you go.
There you go.
So when ChatGPT first came out, right, it was this whole meme of the programming language everyone needs to learn now is English.
Because all you have to do is tell the LLM what you want to do, and it will come out with code, voila, problem solved.
And anyone who has worked on a project before, and especially anyone who's worked with clients before, non-technical clients, knows that the gap between specifying what you want in clear, precise language and getting code that does it can be vast. And the difference between success and failure. I often tell my students one of my favorite lines that I heard years ago, which is computers don't do what you want them to do. They do what you tell them to do.
And like, we've all been bitten by that so many times.
Yeah, we definitely have. We definitely have. All right. Well, I think this is a story that's going to continue to get just more insane. It's going to be interesting to see where things go.
I think it's both going to supercharge open source, but also that super royal cost turbulence for programmers, right? So we're going to see.
No, no question. I 100% agree.
Yeah. So, you know, with all this, we haven't gotten to, I haven't given you a chance to introduce yourself to
everyone because everyone
knows Reuben, but maybe for the couple of people real quick introduction. Fantastic.
So yeah, so I'm Reuben Lerner and I teach Python and Pandas and Git for a living. I've been doing it for a long time, since like 1995 or so. And so half of my work is going to companies and doing training there. And the other half is doing online learning.
I've got my own platform, I've got books, I've got newsletters, YouTube channel, online bootcamp that I do. And my goal is just like to help people wherever they are with their Python Pandas knowledge to advance, get better, get more fluent.
Awesome. Well, that's pretty much the story of this episode as well. But I also, I mean, that's a great introduction, but I didn't know you were such an athlete. I mean, you didn't even talk about all these, these workout books that you're writing and you're a workout influencer.
Yeah. Well, I wish it were more, more, more, more physical than virtual. but yeah, yeah. So I've got my, two books published with Manning, Python Workout and Panda's Workout.
And actually, Python Workout is now in its second edition in early release form.
So it's a relatively minor update to take advantage of all the new stuff that's come out of Python in the last, what, three, four, five years.
So it's not like a huge overhaul, but like something there.
Some of the exercises that everyone kind of said, really, you want to do that?
And so like, yeah, there are always some stinkers in there.
But overall, it's great fun.
And the idea is, you know, Manning and I came with the title, but the idea is you're only going to get better if you do lots of little practice every day.
I often say that it's similar to learning a language, but actually, like I have started running in the last few months.
And like, what do you know?
You do a little more each day, a little more each day.
And then like, you know, every so often you'll get injured, but like, then you go back to it.
And so over time, you build up the strength and the stamina and the fluency so you can really like get into a project and do what you need and not be looking everything up all the time.
You know, one of the things I noticed when I, you know, as you, I've done a lot of in-person corporate training type stuff, not for a while, but, you know, over my career, I think it's really interesting. You go interact with all these folks, some of whom are brand new on a team or a project, but others have been, you know, like I've been at the company for 20 years and that's usually really awesome. However, there's certainly plenty of times that I saw people who had 20 years of experience, but it didn't feel like they had 20 years of experience knowledge in the sense that they kind of did the same thing you did in the first couple years and just kept doing that for 18 more rather than having a wide ranging set of experiences. And it's like a lot of things like exercise, like sports, like other skills without focused practice on something. You can get sort of into a rut or get really good at like a few things, but you're like, well, I've never really created a website. I always just work on this database layer. It's like 20 years. Okay. Spread out of it. Come on. And I feel like this is the kind of stuff you're talking about maybe.
That's exactly it. That you want to get this wide variety of practice. So the books, I don't think I said this explicitly, but the books are all exercises. Like there's some comments in there in some sort of, shall we call it like mini or micro tutorials to get you up to speed. But the idea is you've already learned Python, you've already learned pandas, and now you just need to practice and better that you practice with in what I call controlled frustration in this sort of like, you know, environment where it's not going to matter to your job, then you get to work and your boss is breathing down your neck and you've got deadlines. And I try to make it as varied as possible so that you'll sort of be exposed to as many different ideas as possible. So even if you don't remember it 100% you'd be like oh wait here I probably could have used a dictionary comprehension I don't quite remember exactly what the syntax is but that's probably the right direction and that's way better than uh what do I do now or just doing it the wrong way
yeah absolutely and circling back a bit to our LLM conversation getting exposure to all these things you're like well the LLM wrote this and it looked weird I didn't understand it but now I see what it was doing it was using this thing that I hadn't really played with this aspect of the language I hadn't played with yeah
one of the things i like to do uh with llms is i call the reverse socratic method um where i ask it lots of questions about either my code or like oh you're saying i should do it this way but why and what if i do it this way so instead of like the teacher asks the student lots of questions the students ask the teacher lots of questions that's when we think of the llm as a teacher and i found that i learned a lot of things that way probing both learn the nuances and I see where its limitations are and or where it's just bluffing.
And so I find that to be sort of a useful technique to play with.
Very interesting.
Well, I would propose that Panda's certainly proven itself to be a tad useful.
You know, here and there, there are like a handful of people using it nowadays.
It's astonishing.
I know.
Does it even need an introduction?
I'm not sure that it needs an introduction.
I
mean, if you're listening to
this podcast.
15 seconds.
Yeah, if you're listening.
No, I will. Here's I'll tell listeners out there. There's a very interesting group of people who do listen to this podcast. I'd be interested to hear your thoughts on this. I've had people write to me and they'll say, I really love your show. Thanks so much for doing it. However, you know, I'm I'm starting to understand a lot of the words that you guys are using or what you're talking about. I've been listening for, you know, two months or something. That's the serious persistence to listen for two months and not really like start out not even knowing what's going on.
But a lot of people use this show like language immersion, you know?
You
want to learn Portuguese, you move to Brazil, and then you start learning it, right?
Not the other way around.
So I'm always cognizant of those folks who are using this to kind of as their first step into the industry.
What do you tell those folks Pandas are?
So Pandas is a library, like a module or package in Python that lets you do data analysis.
And the way I describe it to people who are not programmers is it's basically Excel inside of Python.
So you can read in data from a lot of different sources.
You can analyze it in two-dimensional tables, right?
So you've got rows, you've got columns, and then you can perform a ton of different calculations.
You can use dates, you can use text, but you also have all the flexibility of Python as a programming language.
So you can extract different parts of it.
You can mix and match different parts of it.
And Pandas is especially really good at importing from a ton of different sources and exporting back to those sources or those destinations, I guess.
And it's become this, well, to extend the language thing, like this lingua franca, like a lot of people use pandas for even a tiny subset of what it can do just because it's so ridiculously flexible and because it's everywhere.
Yeah, good description.
This portion of Talk Python To Me is brought to you by NordLayer.
NordLayer is a toggle-ready network security platform for modern businesses.
It combines VPN, access control, and threat protection and one easy-to-use platform.
There's no hardware or complex setup, just secure connections and full control in less than 10 minutes.
It's easy to start with quick deployment, step-by-step onboarding, and 24-7 support.
It's easy to combine.
It works with existing setups in all major platforms.
And it's easy to scale.
Add users, features, and servers in just a few clicks.
Single sign-on and provisioning included.
NordLayer provides zero-trust network access-based solutions.
It adds threat protection to keep malware, ransomware, and phishing from reaching your endpoints.
It increases your threat intelligence to spot threats before they escalate, and it helps businesses achieve compliance.
So if you're responsible for the security of your software or data science team, you should definitely give NordLayer a look.
As Talk Python listeners, you'll get an exclusive offer, up to 22% off NordLayer's yearly plans, plus an additional 10% off the top with our coupon.
Just use the code talkpython-10.
That's talkpython-10, all lowercase.
Try NordLayer risk-free with their 14-day money-back guarantee.
Visit talkpython.fm/nordlayer to get started.
That's talkpython.fm/nordlayer.
The link is in your podcast player's show notes.
Thank you to NordLayer for supporting Talk Python and me.
This loading data from multiple data sources, it's nuts.
It's crazy how good it is.
So let me just throw an example out there for people who maybe haven't done a lot with importing data with pandas.
There, you could do things like there is a HTML table on a state government website that talks about some bit of data that you need.
And it's just embedded in some web page.
It's the third table, HTML table, you know, bracket table slash table sort of thing on there.
And you can say, load table, give it that URL and say, or, you know, load that HTML, give me the tables, go to the third one.
And it's a Pandas data frame.
Like that level of just grab it, right?
So I have my, like one of the newsletters I produce is a bamboo weekly where I have like challenges each week to use Pandas.
And I'm always trying to retrieve stuff from different sources because A, people have lots of different needs.
B, there's lots of data out there.
And C, then you have to clean it up and you need different techniques for cleaning it.
And so like, right, you can retrieve it from a PDF file if there are tables there.
You can retrieve, as you said, from HTML, you can retrieve it from Excel, from JSON, from other statistics programs, their binary formats.
It basically is infinite.
And then you've got CSV, which is like every possible almost kind of standard under the sun.
And Pandas is like, oh, that's okay.
We'll just give you 100,000 different options and then you can read any of them.
Yeah, that's amazing.
I'm just blown away with it.
So super, super interesting.
One of the things that I think kind of goes hand in hand with Pandas is, of course, NumPy.
And that's a little bit at the heart of what we're getting at, right?
Like traditionally, Pandas is sort of internally used NumPy to manage its data structures and so on.
And there's some new libraries and formats coming along.
And you might be able to mix and match or even have to mix and match eventually.
Right.
Right. So, so it all started like, so when people hear that, when people hear that Python is the number one language for data science and machine learning and data analytics, if they know anything about Python, they're a little confused. Like, wait a second. Python's a great language, but its data structures are big and slow. Why would I possibly want to use this?
Yeah, especially yours.
I think if you look at like what is most out of sync or out of space with like C or other native languages, right?
Like how big is a Python float versus a regular one and like
locality of
data, all that kind of stuff.
I think the last time I checked, it was like 24 bytes for a zero integer in Python.
Yes, and their pointer dereferences and they're on the heap so they might be in different places.
Like there's a lot going on here.
so
many years ago i don't know 20 years ago or something um we got numpy and numpy is basically like the best of both worlds it's c storage and speed and so all that efficiency but with this really thin layer of python so you can work with it and you sort of get the ease of python and as i said the efficiency of c and so numpy is fantastic at doing that it's very very widely used in science engineering math statistics all that stuff and you could do a ton of stuff with numpy at very happy. But most data analysis that we're going to do is going to be in two-dimensional tables, and it's going to use a lot of strings, and with the import and export that we were talking about. And so I always describe Pandas as like an automatic transmission for NumPy's manual transmission, that you get a lot of sort of convenience functionality that just makes it smoother, cleaner, easier to do your day-to-day stuff. And so Pandas has been reliant on NumPy for, well, since it started, like no doubt about it.
And if you sort of chip away or like scrape away the outer layer there, you very quickly see NumPy stuff.
For example, the D types, the data types that we use in each Pandas column, those are defined almost exclusively by NumPy types.
And so I actually, when I teach Pandas, I first teach NumPy because I feel it's like an easier sort of lower level way to get used to it.
And then they see all the techniques applied to Pandas as well.
Yeah, the data types are interesting because NumPy is written in C.
C operates on structured, well-defined.
You know, this thing is four bytes, that's eight bytes and so on.
Data types.
And so those have really interesting limitations.
I have a joke for you that I ran across recently and I think it highlights this.
So I wish I had a picture I could share of, but I don't.
So there was this programmer that finds one of these genie in a bottle, sort of genie things, rubs it.
The genie pops out and says, hello, lucky one.
You have three wishes.
But before you can wish, there are some rules.
You can't wish to kill someone or make someone fall in love with you.
Most importantly, you can't wish for more wishes.
The programmer says, well, can I wish for fewer wishes?
Why would you wish for fewer wishes?
I just don't understand.
He goes, well, I want negative one wishes.
Fine, you have 2,496,000,300,000.
Oh, that's pretty
good.
So what
happened?
Like, why did that go wrong?
I mean, that's the D types, right?
That's exactly right. That's exactly right. So I never thought of it that way. I always think, maybe because I'm old enough, I think you and I are about the same age, that when you played video games when you were little, if you're really, really good, you would get the maximum score, it would sort of wrap around back to zero. Or
if you had a really
old car, and if you drove it a long time, eventually the odometer would go past zero. There's a
limited number
of digits, and after 9999, it has to go back to 000. And that's basically what's happening bitwise in NumPy. It has a certain set, unlike Python data types, like Python integers will get as big or as small as you have memory. There is no limit. But when you're working with NumPy or with pandas with these d types, you have to say, is it 8 bits or 16 or 32 or 64? And that's it. Once you reach that ceiling, then it wraps around and it will not warn you about this either. So you need to keep enough of a buffer there between what you think will be your maximum number and what could possibly ever be your maximum number. Like if you want to do, I don't know, eight bits for ages, that's probably fine. Right. But if you want to do eight bits for, I don't know, how long is the project going in number of days? Oh, better hope that your project is going to be done soon because you could be in trouble and you could be into negative territory.
Yeah. They should have made a little bit bigger choice for the epoch since 1970, you know, that's right. That's right.
find out in 2038 about that one.
I think
that's the year.
Anyway, it's going to be bad.
Yeah, so the genie was basically storing the wishes count in an unsigned 32-bit integer.
I love that joke.
And I have no one to tell it to, so I'm very glad you told it to me.
Exactly.
What? That's a stupid...
I don't even understand.
What a stupid genie.
Of course, they have no more wishes.
They got some more wishes.
Another thing, you talked about this buffer sort of deal.
If you think maybe you need 16 bits or whatever, or 32, maybe you want to be safe so you're going to double that.
That also adds to a bunch of memory usage.
When you allocate 64-bit integers instead of 32, even if you don't use that space, you consume that much memory.
That's
right. That's the thing.
Again, if you're an even experienced Python programmer, you're like, well, I'll just like whatever the integers need, they need.
But then comes along NumPy and Pandas and they say, no, you have to choose how big it's going to be.
And I'm like, well, okay, let's just make everything 64 bits, right?
What could be the cost?
Just be safe.
Right.
And basically, let's say you have a billion rows that, you know, let's say you just have a billion elements.
Well, 64 bits is going to be like literally twice as much as 32.
And like that could mark the difference between running out of memory and not running out of memory or having to swap.
Like it can get very bad.
And so, especially since Pandas is constrained by what can fit into available RAM.
So you're always stuck with this tension with these D types between you have to keep it bigger, big enough to fit all the data you want, and small enough that you'll be able to fit everything into memory.
And it's a bit of a game.
And there's no formula you can use because you can't know in advance what all your data is going to be usually.
Yeah, for sure.
I mean, honestly, it really freaked me out a little bit when I first started doing Python.
And it didn't matter what integer type I created.
I'm like, well, I give it this number, but what if it gets too big?
How do I control that?
You know, you don't.
It's just, it's magic.
Right, right.
And I come from like a dynamic language background.
Like I was always sort of brainwashed to think this is the way normal things are.
And so when I was like told that there are languages where you have to say how many bits it's going to be in advance, I was like, wait, what kind of crazy stuff is this?
But it turns out a very large number of people see that as totally normal.
Yeah, it's interesting.
I was just looking at some C-sharp stuff last night and all the symbols and all the stuff there.
Like it seems normal when you're in that.
Then you step out of it.
Like, wait, I don't have to be constrained by this or I don't have to worry about that particular thing.
That's weird.
But wait, if I don't have to worry about it, why have I been spending all my time and energy thinking about it?
Right. But I mean, I would say most languages, actually, you probably do have to worry about your numerical sizes.
Right. Anything that's sort of compiled and allocates things like that, you work with memory.
Look, it's like a statically type versus dynamically type language sort of thing.
Right. Do
you want to have that extra safety? Do you want to know in advance how much memory you're going to use?
Or do you want it to be more expressive and flexible, but then potentially have problems if you don't think about it enough in advance?
Yeah,
yeah, yeah.
Yeah, for sure.
All right.
So that's, I guess, one more thing before we move on to talk about Arrow.
You can ask Pandas how much data a data frame is consuming, right?
So the answer is, as always with me, yes and no.
You can ask it how much memory it's using, and it will give you an answer.
And sometimes that answer is even accurate.
And the problem is basically that it will tell you how much memory is being used in NumPy.
And so if you've got integers, if you've got floats, if you've got date times, it will be 100% accurate.
The moment that you have strings or other objects, but let's just concentrate on strings, NumPy does have strings, and they're terrible.
And so basically, Pandas is like, we're not going to use those.
we're going to use Python strings, and we'll just store a pointer in NumPy, a 64-bit pointer that points the Python string, which means that if it calculates how much memory is being used by NumPy, it's showing you how big the pointer is, which is potentially, I mean, there is no connection.
There's no correlation between that and the size of the string.
All strings are eight bytes.
That's right.
That's
right.
Well, we washed our heads of that one.
And so when you use df.info, use the info method on a data frame, it will report back. And then sometimes it'll put a plus after that number. And the plus means, hey, I've got some strings here in Python memory.
I'm going to just give you a fast answer. And I'm not going to go explore that. If you really want a real answer, tell me basically deep equals true. And then I'll go off and explore our Python memory. It'll take longer, but you'll get an accurate count. And that's surprising to a lot people, including because the index and the column names are also typically strings. And so the moment you have an index or column names assigned, it'll also give you that plus and you can't depend on it.
Yeah. Interesting. And you know, Python objects have the same issue. If you ask in Python, I can't remember exactly what the
size of.
Yeah. Get size of that's it. Yeah. And that will, that does the exact same thing. So if you've got a list, for example, or a dictionary, and you ask how big is it, it's like, well, it's basically how many pointers are stored in its structure that point out the things. And for the memory class I did at Talk Python, I had to write some code that would basically traverse the object graph of all the structures. And like, no, this is actually how big it is. And this is why it's doing this in memory and so on. And yeah, it's not unique to NumPy, but it's,
yeah,
it's just, you got pointers. It's a lot more work to traverse them and figure that stuff all out. Okay. So there's a lot of energy around a specification, a library called Arrow from Apache, Apache Arrow. It's the universal columnar, where it always catches me up, columnar format and multi-language toolbox or fast data interchange and in-memory analytics. And so this is, this is super interesting in this project. Let me go to its, it's a homepage or whatever.
But yeah, you have this for many different languages, right?
It's not just Python.
In fact, it's like NumPy written and this one's written in C++.
Yeah, I mean, so think about it this way.
Like, I mean, I always sort of think about my evolution of seeing amazing stuff in programming languages.
So it used to be really amazing that you could get strings, right?
Back, let's get 30 years ago.
Wow, you don't think about like, you know, arrays of characters.
It's just a string.
Amazing.
Fast forward a number of years and I was amazed by dates and times.
And nowadays, like everyone wants to do data frames.
And so Wes McKinney, a bunch of other people, like he invented pandas, said, well, why don't we, instead of everyone inventing our own thing, why don't we create a backend data storage system that everyone can use that does all the data frame stuff?
Because we all want them in our languages.
And then we can make it really fast and universal and do lots of inputs and outputs and even have interchange among these different languages.
And so that's what Arrow is basically trying to do.
It's trying to be like the universal, super fast, super efficient data frame implementation.
So your pandas library just needs to be a layer on top of that, which might have some echoes of just being a layer on top of NumPy.
Yeah, it sounds similar.
It sounds familiar.
Yeah, very cool.
So let's talk about this columnar thing, columnar aspect of it.
So I guess pandas and NumPy operate on the concept of rows.
I've got rows of data and arrow is more about, I have columns of data that are, could somehow have row definitions into them.
And it lets you ask different questions more or less easy, right?
Depending on what you're trying to ask, like what is the average of the miles per hour?
Like, oh, well, that's just this thing.
I go right down the column and boom, here's the answer, you know?
Or you start asking that by rows and arrow, then it's got to do a lot of work.
to kind of piece that together and quite the opposite for
pandas, right?
So I'm still digging into exactly like what's going on there.
What you said is I think true, but it's also true that pandas data frames, you can think of them, I think of them as like a dictionary of series where each column is actually a series.
So it's not really row by row, but the numply implementation is row by row.
So I think like something in the backend there is being translated differently, but it is 100% true that Arrow is just way faster doing analysis of a column um numpy might be faster at adding elements or like doing that sort of thing but the moment that you want to as you said like get the mean or get the min or the max or like sum them up or whatever arrow is just like blazingly fast because that's what it was very specifically designed to do yeah
you just you preload the data you got to load into some kind of data structure right and you can do that in ways that optimize some things at the cost for others. I think there's a
little
bit of a similarity between relational databases and document NoSQL ones in
the sense like
their data is structured in one way for really good operations, right? Like I want to go through this table really well and I want to maybe follow a relationship that's set up really well, but you're still computing all those things because they're in like different places in relational ones. And then like say a document database, if you know there's always this relationship you follow. You can just put them together and like kind of pre-compute them. But that makes other questions that don't follow that relationship, but like use the nested data super, not super hard, but much harder than it otherwise would be, right? So it's all about these trade-offs and how you store stuff. You know, what kind of questions are you going to ask it?
That's right. Arrow like goes even further than that. Like it does compression because it says, well, if I've got all this stuff in the column and I see a lot of the same things, I'll as compressive. Also, it has strings. So we don't have to, like Arrow has its own implementation of strings in its binary format right there, which again, you know, we were talking a few minutes ago about how currently Pandas ignores NumPy strings. And so it uses Python strings. And so Arrow offers the opportunity of having them right there in memory nicely and efficiently.
This portion of Talk Python is brought to you by Auth0. Do you struggle with authentication?
Sure, you can start with usernames and passwords, but what about single sign-on, social auth, integration with AI agents?
It can quickly become a major time sink, and rarely is authentication your core business.
It's just table stakes that you've got to get right before you can move on to building your actual product.
That's why you should consider Auth0.
Auth0 is an easy-to-implement, adaptable authentication and authorization platform.
Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 different SDKs and quick starts, Auth0 scales with your product at every stage.
Auth0 lets you implement secure authentication and authorization for your preferred deployment environment.
You can use all of your favorite tools and frameworks, whether it's Flask, Django, FastAPI, or something else, to manage user logins, roles, and permissions.
Leave authentication to Auth0 so that you can start focusing on the features your users will love.
Auth0's latest innovation, Auth4Gen AI, which is now available in developer preview.
Secure your agentic apps and integrate with the Gen AI ecosystem using features like user authentication for AI agents, token vault, async authorization, and FGA for RAG.
So if you're a Python developer or data scientist looking for an easy and powerful way to secure your applications, Get started now with up to 25,000 monthly active users for free at talkpython.fm/auth0.
That's talkpython.fm/auth0.
The link is in your podcast player's show notes.
Thank you to Auth0 for supporting the show.
Now we have PyArrow.
What's the relationship between
Arrow and PyArrow?
So that's actually simple to explain, which is PyArrow is just the Python client for Arrow.
So you want to use Arrow.
you're a Python developer, you do import PyArrow, and you now have these data structures available.
By the way, you can do that without pandas.
If you are like a pandas hater, or you just have no interest in using it, but you want really fast data storage, use PyArrow.
And there's nothing wrong with that.
I'll even say that my interest in PyArrow and pandas started a few years ago.
I saw a talk at a conference somewhere, and I was so incredibly confused.
I was like, okay, so there's PyArrow and there's pandas, And they say there's a relationship, but what is that relationship?
I have no idea.
And that's
what like...
Because it's all NumPy.
NumPy has nothing to do with it.
What's going on here?
Right, right, right.
So you can use PyArrow and there's nothing wrong with it.
And it has a rich set of data types and all sorts of really amazing functionality.
And of course, it's super fast.
Yeah, somewhere in here, I was looking around for which...
There's a list that says, here's all the different languages that's supported on the Arrow project.
And yeah, it's the implementation status, I believe.
And so it says, well, what data types are supported per language?
So there's like a Java implementation and a C# implementation and a Julia and a Swift and a Nano and a Rust and so on.
And I'm looking through here and like, obviously, the C++ one has pretty much everything supported.
Whereas, say, the Java one doesn't do decimal 32 or 64, but it does floats or does the big, the really big decimals.
you know, things like that, 120 bit and so on.
And I'm like, something is wrong.
There's something is throwing me off here because I know there's a real popular Python and I don't, Python is not listed as a language.
So that's throwing me off.
Like, why is this?
So I'm like, oh, under the
details,
it says, unless otherwise stated, Python, R, Ruby, and C, G, Lib libraries are following the C++ error library because there's like a really native tie to the original C++ version.
Isn't that interesting?
So I think it also means those languages, like those are all dynamic languages.
Well, not C, Glib, but like the dynamic languages there are, I think, these thin layers that just talk directly to the C++
implementation.
Yeah,
exactly.
And so it's like, whatever that can do, we can do too.
Zoom.
Yeah, exactly.
Exactly.
So I think when you think about PyArrow, I feel like you almost should just think about the C++ layer.
Or if you hear features of Arrow, look at the C++ stuff because PyArrow is just, like you say, a very thin wrapper on top of that.
But at first when I look, it's like, what?
They're talking about C# and Java?
No Python in this?
I mean, surely there's enough data science in Python to warrant a checkbox or a check column.
They're like, we're so great, we don't even need a column.
Exactly.
Yeah.
We're the native column.
Anyway, I think that's really interesting.
So I do want to go, I think this little data types thing gives us a bit of a jumping off point for circling back a little bit.
Why did I bring up that genie joke, right?
Other than I really like it.
I think it's funny.
But we also have these D-type concepts down in the C++ layer, which is really no different in terms of data types than C, right?
There's still 4-bit or 8-bit numbers and so on, signed or unsigned.
and
you have this here but pi arrow and more generally arrow deals with that differently right if you have overflows or missing numbers it's not exactly the same as you know negative or certain positive 20 2.4 billion or whatever it is right
i mean so so yeah well the whole missing data thing is a whole problem in and of itself so like i mean there's missing data in every data set we have right so people forget to enter stuff and sensors go dead and like networks are down, all sorts of stuff. So what do you do if the data is missing? Because you can't just like have a blank space there. And so like for many people, they're natural, like if they're new to this, their natural assumption is, oh, well, I'll just do like a minus one or I'll use zero and then it'll be great. And like you think about, well, what happens if the temperature sensors are dead? Okay, fine. So maybe we'll use minus 999. Well, wait, that's probably not so good either.
And so after like, it's been a number of years that people have realized, okay, we need a totally separate thing to indicate that data is missing. And so that's where NAN comes in, not a number, or in modern Python, it would be NA. But then you get into other issues of, well, wait, what type is NA or what type is NAN? And it turns out that NAN in traditional NumPy is a float.
And so if you have a bunch of strings and you want to say there's a missing value, oh, wait a second. So now we've got strings and we've got this float. Oh, no. And it just like goes downhill from there. And so one of the amazing things that Arrow did from the get-go was to say all these types, all these values we have are nullable, meaning that there is a specific value of nan or na or whatnot that fits with all these things. So you can have integers and na, you can have strings and na. You can even have the first row of that table you're showing there is null. It's kind of wild. But if your column contains only null values, then it will be defined to have a null D type.
And then it's just like, oh yeah, we got 10 nulls.
And then it's like almost zero storage.
And so PyO took this into account and it means then that your data is, it's no less accurate, but it's also tighter, easier to work with and more predictable.
Yeah, if you use a sentinel number or something for missing data, like you're seeing like negative 999, that may or may not work, but you better not ask what the average temperature is.
It's just really cold there.
I thought Hawaii was nice, But no, it's cold.
That's right.
Yeah, yeah.
Another interesting aspect of arrow, C++ arrow, pi arrow, same thing, is the copy on write aspect to save memory, right?
So maybe you've got a string that appears a lot of times like Kansas or Oregon or New Jersey or wherever, and you've got a million rows of those.
Do you need that string repeated a million times, right?
That's right.
So it's much smarter about that sort of stuff.
Like, you know, it's always easier to design a software system second time around when you see where all the issues were.
And I think that they took a lot of the lessons from be it Pandas, be it R, be it Apache Spark, all these things.
They're like, okay, where are there inefficiencies for the program or where are there inefficiencies in the system?
And let's try to just like solve those problems as best as we can for the general public so they don't have to think about this.
And yeah, that's part of like, so it gets way, way faster, way, way smaller.
Yeah, we opened our pandas discussion.
We're talking about importing data from lots of different sources.
And it seems like Arrow might be slower because if it's doing compression, if it's doing deduping and all these types of things, it seems like it would be slower, but it's actually not.
Like loading CSVs is way faster
and these types of things, right?
Oh my God, there's no comparison.
So loading CSVs, and this is one of those things where Pyro, we'll get to this in a bit, But like Pyro will eventually like replace NumPy.
But even today, like when we're recording, you can with like very confidently use PyArrow to read in your CSV files in Pandas.
It won't change how it's stored.
It'll still be stored in NumPy.
I think, I'm not 100% sure, but I think that it does multi-threading and splitting up the file and all that stuff that we would sort of want it to do.
So it's like blazingly fast.
I'll even say like a few days ago, I was talking with people, I even put up a YouTube video about this I'm just so floored.
So reading in an Excel file, I always thought, okay, Excel's a binary format.
So I'll read it and it'll be nice and fast.
And it took over a minute for me to read it in Excel.
And then I tried it basically using one of the arrow binary formats that it has defined.
I guess we'll talk about it a little bit because I'm jumping on a bit.
And it was, I'm not exaggerating here, 2,000 times faster.
It was so ridiculously, ridiculously fast because
it
is like so optimized for doing like one job and just that one job.
Incredible. Yeah, you think Excel would be optimized for loading data, but I mean, Excel, the app is, but I'm pretty sure that the XLXS, whatever, like the format, I think that is a zip file that internally contains a probably namespace laden XML.
document.
You are good. So someone, one of my subscribers to Benful Weekly emailed me and he said, okay, I get it. You're an open source kind of guy. You're not up on all the Excel formats.
Let me explain to you. Just last night we had office hours and he like went into it in more details. So you're spot on. XLSX is
a zip file.
You can actually unzip it and you can see all the XML files inside. And so that unzipping and that XML deserialization and so forth, that is where it's taking a ridiculously long time.
Right.
And apparently they didn't optimize for load speed, optimize for other stuff.
And maybe that's the right choice for Excel.
But this is like coming back to like, okay, we need to fix some of these problems.
And what is the most common thing we do?
Let's optimize for that, right?
Kind of like columnar versus rows.
So that brings us to a couple of file formats that are pretty interesting.
Talk about Parquet first.
By the way, I will admit, I have no idea if you're supposed to say Parquet or Parquet.
So I'll go with you and parquet.
I know that like the flooring is parquet, but whatever.
You know what?
I'm going to ask ChatGPT.
It's always good at pronouncing things.
So the basic idea is, okay, like the Arrow people came up with a great way of representing things efficiently in memory.
So they said, well, what about representing that on disk?
And they actually came up with two file formats because, you know, there are different tradeoffs we want to make.
And Parquet format is like a sort of very, I don't know, verbatim version of, no, yeah, it's actually compressed.
It's taking the binary data that we have and compressing it.
What's the good news?
Takes very little space on disk.
The bad news is it takes a little bit extra time to do the compression decompression when you're saving and loading.
Feather is the same idea.
It just doesn't get compressed.
So it takes up more disk space, but it's faster to load and save.
In either one of these cases, you will be completely and utterly blown away by how fast they are.
And the fact that they are binary formats that are exactly the same D types as you have in Arrow means there's no more guessing, there's no more playing around with CSV and having them nudged in the right direction.
There's no more of this really long loading with Excel that we were just talking about.
It just like screamingly fast pulls it into memory with exactly the D types that you wanted.
Yeah, super interesting there, I think.
Like, it's
still, I see too many, like, because I deal with a lot of public data sets.
And I see overwhelmingly they're still using CSV and Arrow.
I'm sorry, CSV and Excel.
Here and there, here and there, I'm starting to see people make things available in parquet format and feather format.
So, like, it's making some inroads among the, like, data savvy.
Yeah, well, what I was going to ask is, what do you think about the workflow?
So, I'm going to work on a data science project.
I've got a 200 meg CSV file that takes forever to load.
maybe the first thing I do is convert it to either, probably I convert it to Parquet.
I'm going with that French-ish pronunciation as well.
I convert it to Parquet files.
And then from then on, my program just works with it.
Maybe even at the start of your notebook or start of your code, you say, what is the last change of the Parquet file and the CSV?
And if the CSV is newer, then regenerate.
Some little guard like that.
But just keep your CSV file as part of your project.
but operationally swap it over to one of these new formats and just work with that.
I would a hundred percent go in that direction.
It's, it's like, you know, if you start using uv, you're like, Oh my God, I can't, I can't believe
it.
I'm not going back.
I wasted so many
days of my life waiting for pip to do its thing.
And in the same way, when you start reading in files from Parquet, like as opposed to CSV files or
even a cell,
you're like, Oh my God, this is like, it just happens so fast that you can't even believe it.
Again, Like in
my YouTube video, like I show, I use time, like, no, I didn't use time it.
I just like ran, like loaded in Excel once and took like, again, a minute, 20 seconds.
And then I actually used at time it in Jupyter to load it from parquet format.
And it was very happy to do a whole bunch of different loops and still ended up like way, way, way faster because it was so much, so ridiculously fast.
Yeah.
Super interesting.
And I think this is a big opportunity here for people to really, you could probably even for the sufficiently large project, maybe you're not even wanting to use Arrow, but you could still probably load up a data frame in PyArrow and then you can call like two pandas or something like that on it, right?
Right, although, I mean, you could, you definitely could.
And that's how I was like sort of first introduced to Arrow.
It's like
That's a gentle introduction.
Right, like, right. It was like, well, here's Arrow and here's pandas. And look, you can convert between the two. But I mean, you can. And maybe there are a lot of people doing that.
I just feel like, you know what, if I'm going to use Arrow, if I'm going to use PyArrow now, I'm just going to do it like directly inside of Pandas, inside my data frame and get like the best of both worlds.
Right. Super interesting.
So that's one of the big aspects or areas you focus on in your upcoming PyCon talk is that increasingly there's a way to say, I want to use Pandas, but Pandas don't use NumPy as your underlying storage engine.
Use Arrow instead.
That's right. That's right.
So at
some point,
and it's not clear when, it's like they're going to make the switch where PyArrow will be the default storage and NumPy will be like an optional way to do it.
Right now, it's not even the opposite of that.
Right now, you can specify when you do a read CSV or read Excel or whatever, you can say dtype backend equals PyArrow.
And then they have in like big bold letters, this is experimental, do not use in production, here be dragons, that sort of thing.
But if you do do it, if you're a little like, you know, if you're willing to experiment, then the D types you see are not NumPy D types.
They are PyArrow D types.
And you can see the difference very clearly because it won't say N64.
It'll say N64, square brackets, PyArrow.
So it's very obvious to your eyes when you look at the D types.
And it is blazingly, blazingly fast at anything you want to do on a column.
So you want to do mean.
You want to do max.
You want to like, even when you do like group buys, I have in my talk, I have a whole bunch of graphs that I do.
And there are a few graphs where the bar for NumPy pandas and the bar for Pyro pandas, you only see one bar because a Pyro data frame was so fast that like, it's just like basically
Might as well be zero. Right.
So I wouldn't say people should run out and put this in production just yet, but with every passing month or two, it's getting better and faster and more stable.
And this is definitely the direction in which we're going.
Very interesting.
And so when you make that recommendation, like stable versus non-stable production, not production, I feel like that probably is a statement on Pandas plus PyArrow integrated, not a statement on Arrow itself.
That's exactly right.
That's right.
The core developers are still like cautioning us because they're still like issues.
And I don't even know, when I first started using PyArrow inside Pandas, I guess about two years ago, and I tried to do a bunch of string methods and said, hey, this string method is not even implemented.
And now, as far as I can tell, all the string methods are.
But there are all sorts of holes that I have not encountered that I'm sure exist.
And there's also one big sort of downside of using Pyro, which is if you try to retrieve things by row.
So if you're doing like.ilock to retrieve by row location, it is way slower than NumPy.
Because suddenly it's like, oh, wait, you want to do biro?
Oh, we're not so good at that.
Hold your horses.
Now, how often do you do that?
Maybe not that often.
Maybe it's not that big of a game changer.
But you do need to take that into consideration.
It's not a 100% win.
It's also, you can convert from the NumPy version to the PyArrow version, right?
Yeah, yeah.
So there are two different things there.
So one is if you have like a data frame.
And so you can always use the as type method to take a series and get a new series back from it with a new D type.
So if I have N64 and I want to make it N32 or vice versa, I say dot as type, the destination D type, I get back a series.
I can assign it back to that original column and it'll work just fine.
So instead I can say as type N64 py arrow and then assign it back and you can mix and match the D types.
So you can have a data frame in which some D types are py arrow, some D types are numpy.
Now, I just discovered literally in the last few days in preparation for updating my talk that there is a pandas option.
Let's see, what is it?
It is, I wrote this down here, future.infer string.
So if you said
future.infer
string to be true, and then you load a CSV, all of your strings will be py arrow strings as opposed to Python strings as opposed to NumPy strings.
And they are marked as, this has got to be like someone came up with this, NumPy.
pyarrow. Now, what does that mean? It means that it's stored in pyarrow, but it uses some sort of numpy API accessor so that like pandas doesn't freak out, something like that. But it still uses like the pyarrow storage. So you're not going out to Python memory. It uses dramatically less memory than before and it's dramatically faster. And that seems like an in-betweeny step that people might want to adopt if they have a lot of string data.
And that is an interesting step. Do you have, When you uv pip install pandas, do you have to do also include py arrow in order to get these features or does it come along?
So the official statement that I've seen is that pandas three will, and I don't think there's a release date for that, pandas three will require py arrow as a dependency.
So even though they're not going to change the default, it'll still be default using numpy, we'll have to have it around.
I don't believe that it's automatically installed when you install pandas now.
So I believe that you have to like pip install like
both of them.
It would probably raise an exception if you said the D type was string bracket pyro, but it didn't have pyro.
Yes, yes, for sure.
And I haven't done a lot of investigation to this, but it seems that like pyro has a lot of rich data types.
And it even has like lists and structs.
And it seems that pandas now has, just as it has.store and.dt to get to strings and date times, it has like a.list and a.struct.
I've literally like written that down as something to investigate before I like do my talk next month.
But it seems that they're trying to expose these complex arrow data structures from within pandas as well.
How many people are really gonna use it?
I'm not sure, but it seems kind of interesting.
It's gonna be interesting to see what the row-based operation performance, what happens to that, you know?
I'm just thinking, is it almost at the point currently, if it's slow enough, that if you know you're about to enter into a whole bunch of asking a bunch of row oriented questions, do you convert it to a NumPy based data frame?
Then ask a bunch of questions and then like throw that away and carry on?
Or I don't know.
No, like, you know, I've been thinking about, well, OK, how many row operations do I really do?
And it turns out not to be that many.
Like, I think they're making the right call here.
Oh,
of course.
it can't be like i just don't think that they're going to leave it this slow um and i see i can't remember exactly what it was but when i started playing with pyro i remember i think it was grouping i think it was grouping or maybe joining one of those two was really really slow and i was in touch with one of the core developers and they were like don't worry we know we're working on it that's why it's still not ready for prime time and it's definitely improved a ton since then so there are definitely people like working hard on this stuff yeah
there's probably some data structures they can compute at load time that allow them more efficient iteration of row oriented data if it turns out to be a problem maybe i don't know maybe you set a flag like you know include optimizations for rows or whatever right and so it like does a little extra work to to pre-compute like let me ask questions of like that data structure and then that maps into the real columnar structure or whatever i don't know who knows it'll be interesting to see where it goes though
yeah for
sure for sure so once you have columnar data or you just have py arrow underneath in general it leads into the possibility of more direct interaction with other libraries like thinking of things like duck tv right duck tv is really focused on analytics more than rows like kind of sqlite versus duck
tv is kind
of the same thing as you know pandas versus py arrow type thing What do you think about the interop there?
Is that making differences?
I haven't played with DuckDB.
What are your thoughts?
So first of all, I played with DuckDB and it is just like astonishingly fast.
Like it amazes me that something that queries Pandas data frames can be faster than Pandas itself.
Right, you think that would be the, how could it possibly outrun the thing that is its foundation as part of that conversation, right?
Like how could that be?
And yet it is.
So I increasingly see it this way, that pandas, as much as people love to hate it, and they say, oh, it's got this problem and that problem and so on and so forth, it's becoming, as much as it is a package, it's becoming like a pluggable infrastructure that you'll be able to have different backend storage facilities like NumPy, PyArrow, and then those will talk to databases and so forth.
And then the query structure is also looking pluggable in some ways, whether it's DuckDB or FireDucks, or like, who knows, people will come up with more stuff.
And so you'll be able to sort of use Pandas without using Pandas almost.
And like choose your weapon.
I don't know.
I don't know where this is heading.
But I think it just cements Pandas as like not just the default over stuck with it.
But it's like the sort of meeting place for all these data manipulation libraries in the Python world.
Yeah.
Very interesting.
You know, the other big contender, I suppose, is probably Polars, right?
Right.
for solving these types of problems and so on.
And I believe it's also based on Pyro, right?
I believe so, right.
And so a lot of it's speed.
I mean, look, I have only the most positive things to say about the developers and the people working on it and people using it.
It is indeed astonishingly fast.
And I think that's partly due to Arrow and partly due to like very hard work by Richie and so forth.
I just don't see it like sort of pushing pandas aside
simply because
it's too entrenched.
um i don't know if you remember again like i'm dating myself uh but like years ago the lisp people were furious that c was like the main language and there was this famous uh article called worse is better um that basically said how can it be that lisp is not the number one language when we all know it's fantastic how can this terrible language c be taking over the world and the answer was well it's everywhere and they've made a like a good good run of getting it everywhere so tough luck and i think in some ways
even
if folders is better like pandas is there and people are using it and you go try telling all these banks nah we're gonna like we're gonna throw out all the pandas work we've done in the last few years and put in bowlers just not gonna happen
no it's not gonna happen i do think there's interesting libraries like um i interviewed marco from narwhals which is like an interoperability story between those two.
I've heard about it.
I've heard you talk about it.
I've played with it a tiny, tiny bit, but not enough to really have a real opinion.
But as far as I'm concerned, anything that does interoperability, like fantastic.
It's pretty interesting in that it basically, it knows if you pass it a Pandas data frame or a Polars data frame, and then it kind of adapts what it does to allow you to sort of operate on either kind of with the same operations, which is pretty interesting.
but you do have to use the Polars API.
So that's something there, I suppose.
Yeah, and I think this PyArrow change that's coming along, it's going to be powerful, right?
Certainly the speed is going to be well appreciated.
The ability to load larger amounts of data rather than duplicating a bunch of strings.
It's great.
But what do you see as the pitfalls or the challenges?
We're getting short on time here.
Maybe we could wrap it up with both a statement of encouragement and steps to take, but also maybe warnings to be looking out for?
I don't think I have too many warnings.
Like so far, I think the Pandas core developers have been very cautious and slow.
Probably some people would argue too slow, but I think it's good.
Like this is people's data.
This is like a serious thing.
Take it slowly.
Be careful.
Make sure everything is really working the right way and working quickly.
But I think like it's very encouraging.
And I would say if you're using pandas right now, it's worth doing like taking a little detour for a little bit of time.
Try out PyArrow. Try out these other details.
At the very least, you should certainly be using PyArrow to be loading your CSVs.
And you should even try out this loading of strings that I just discovered recently.
I think just those things alone might speed up your pipeline to give you faster iterations and feel better about it.
And just be ready at some point, right?
At some point in the next few years, I don't know exactly when, they're going to flip that switch and say Pyro is now the default.
And you will be able to, I find it possible to believe that they're going to say, and we're chucking NumPy.
That's not going to happen.
But you will need to say explicitly, I want to stick with it.
And some people, I think a lot of people are going to find it advantageous to make that change along with Pandas.
It's going to be exciting.
It is going to be exciting.
So one area maybe I could ask you about is reproducibility.
That matters for businesses.
like you want to go like well we ran this report and we made this important decision to spend a billion dollars on this thing based on this analysis it's still good we make a mistake but certainly in the sciences right like people build upon papers and theories as if they are perfectly solid building blocks and if those things were to have trouble that would be a real big problem you want to be able to rerun your code 10 15 years later changes like this could make it not tomorrow or the next day, but eventually you could see it drifting far enough where it's like, oh, we're kind of done with NumPy and we're moving on to this thing.
And eventually it might be tricky to get exact reproducibility.
Right, it's sort of like, I remember I saw a talk about porting, if I remember correctly, like NumPy to Wasm.
And they were like, did you know that NumPy requires Fortran?
And so we had to like, like, I think it's NumPy.
Like there was some part of this whole
input, like
the PyData stack, And none of us would have expected this because we're all like Fortran, right?
Who uses that?
But it turns out, right, people use these things.
So people are going to have to take this into account.
I think NumPy will still be around.
Look, it's still a very actively used package.
It's just not a good match for a lot of things that Pandas is doing.
So you might need to, I don't know, put in your package specification what versions you want, that you do want NumPy to be included.
Like it might be a little harder in the future.
I don't think, like there's enough of an installed base.
I don't think they're going to just like throw people to the wolves.
I think it's going to be, it's not going to be a Python two to three situation.
I
think none of us have enough like
emotional scarring that it's not going to happen.
Yeah, I agree.
I don't think it will happen.
I'm just thinking, you know, over the long term, you can see sort of a slight eroding to the point where maybe, I mean, do we really think about running the same code 20 years later?
Sometimes, but not that often.
I
mean, Python's only 30
years old.
NumPy's only 20, right?
That's double its life, right?
That's a long ways out.
Pandas is less old.
Right, right.
I'm not too worried about that, but someone somewhere is going to get the short end of the stick a number of years from now, and that's okay.
That's what their grad students are for.
Rewrite it.
No, more seriously, maybe pin your versions, right?
If you're doing any sort of reproducibility, definitely pin your versions, but maybe even, you know, download some wheels and just hang on to some wheels for
Linux or
do a Docker sort of thing or something like that.
Who knows?
That's right.
All right.
And all these problems are obviously a sign of it being so successful, right?
Pandas being so successful.
Oh, for sure.
What was it?
Like the numbers are just astonishing.
I think the last estimate were like they're between 5 and 10 million people using pandas nowadays.
And let's assume that's like off by a factor of 10.
It's still an astonishing number.
It is astonishing.
It's amazing. Well, we're going to be at PyCon. I got to book some stuff.
In like five weeks from the time of recording, even less time from the time of release, maybe two weeks. Tell people about your talk. They can come see your dive into this, which I think will be fairly different. We didn't just go right down the slides of your talk or nothing like that. So
there's a lot to learn from
going to your talk.
Yeah. The talk is much more like code oriented. Like here are like, here's how it looks. Here's how it works. Here's the like speed comparison. Here's where it's better. Here's where it's worse. so yeah.
I never even people told, I haven't told people about the title.
Oh yes. So it's called the pie, the pie arrow revolution in pandas.
Yeah. So it's going
to be Friday morning. I think I'm telling the truth there. And get
people, people while they're fresh.
Yeah, exactly. I will not be standing between them and lunch, which has often been the case in previous talks and don't strangely don't get a lot of questions then that's
interesting i wonder how that works no you don't want that and you don't want the last talk of the day the last talk of the conference but i mean it's still good people still appreciate it but it's just it's the reality of travel and airplanes and hunger and all these things so really good i encourage people to go check out your talk and it should be fun it should probably be up on youtube i don't know what the time frame this year for talks being converted to youtube videos will be but eventually
yeah usually it's like well like two months or so after the
confident. Yeah, something like that.
I'm pretty confident.
Yeah, absolutely.
Indeed.
Reuven, always great to catch up with you.
Thanks for being on the show. My
great pleasure. I'll see you in a moment.
Yep. Bye.
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 brought to you by NordLayer. NordLayer is a toggle-ready network security platform built for modern businesses. It combines VPN, access control, and threat protection in one easy-to-use platform. Visit talkpython.fm/nordlayer and remember to use the code talkpython dash 10. And it's brought to you by Auth0. Auth0 is an easy to implement adaptable authentication and authorization platform. Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control. With over 30 SDKs and quick starts, Auth0 scales with your product at every stage.
Get 25,000 monthly active users for free at talkpython.fm/auth zero.
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.