Peter Wang has been pushing Python forward since the early days of its data science roots.
We're lucky to have him back on the show.
We're going to talk about the Anaconda toolbox for Excel,
as well as many other trends and topics that are hot in the Python space right now.
I'm sure you're going to enjoy listening to the two of us
exchange our takes on the topics and trends.
This is Talk Python to Me, episode 489, recorded November 26, 2024.
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 Sentry.
Don't let those errors go unnoticed.
Use Sentry like we do here at Talk Python.
Sign up at talkpython.fm/sentry.
And this episode is brought to you by Bluehost.
Do you need a website fast?
Get Bluehost.
Their AI builds your WordPress site in minutes, and their built-in tools optimize your growth.
Don't wait.
Visit talkpython.fm/bluehost to get started.
Peter, welcome back to Talk Python to Me.
Well, thank you so much for having me.
It's great to be here.
It's always good to have you.
I love your perspective on things.
It's always very thoughtful and fun, and I don't see why this would be any different.
We're going to have a great time.
I'm looking forward to the conversation very much.
I am as well.
So let's, you know, you've been on the show a number of times, but let's maybe just have you do a quick introduction for yourself.
Just for people who don't know you.
Who are you?
I am, yes.
So I am the co-founder at Anaconda.
I also helped create the PyData movement.
So really taking the Python, scientific Python numerical ecosystem into the world of data analysis and open source data science.
I guess 12 years ago we started.
And I've created a number of open source tools, some more popular than others.
But really, I think maybe my biggest role and contribution to the ecosystem has been as sort of a community steward or as someone who's been, you know, really trying to help drive commercial adoption and really trying to make sure that there are on ramps for businesses, large scale and small scale, to adopt Python and continue using Python.
And that really, a lot of my perspective there, even though, of course, many of my colleagues in the open source Python community have spent a lot of time as developers in startups and, you know, big high tech companies.
One of the things that I learned early on as a consultant was that enterprises have a very, very different approach to adopting technology and open source even now can still be challenging to them.
So there's a role for some of us to play in that commercialization and advocacy for open source.
And, you know, 15 years ago, I was advocating for Python in, you know, rooms full of Java and .NET, very, very stodgy and angry Java and .NET architects.
And now, you know, it's sort of.
How could you possibly come and recommend a dynamic language for our professional software?
It doesn't even have types.
It's got this white space stuff.
It doesn't.
Do you have tabs or space?
I mean, yeah, I lived.
I mean, I have, you know, a thousand yard stare thinking about some of those meetings sometimes.
But we prevailed.
And now we have the other side.
We have the flip side of the coin, which is that our little technology ecosystem has now grown up.
It's crossed the chasm.
And now everyone's using it, even if they don't like it.
Even if they kind of hate it.
They have to use it because now it's a thing everyone does use.
And so conversely, so the flip side of the coin is defending Python, even when it is ubiquitous.
So it's really interesting having to engage in these different dynamics of the conversation and then also trying to bring my perspective into conversations as the ecosystem matures and the cast of players is different.
So it's just been, you know, honestly, I just feel a great deal of gratitude towards the community, towards many of the great people I've met.
People like you, you know, I mean, how the energy it takes to run a series like you've done for as many years as you've done it.
It is almost 10 years now.
It's unbelievable.
It's just such, it's really oftentimes very, very, it's under-recognized work, I would say, as, you know, a community advocate and as someone who elevates so many great voices in the community.
And so all of us kind of in the Python tribe ecosystem, you know, we're all trying to do our best to kind of make things go, but it's just been really wonderful to see the impact that we've had.
And I think a lot of the work that we did did lay the groundwork for modern machine learning and then, you know, making GPUs accessible and usable.
And now Python is the language that everyone is doing AI in, you know, whether they're deep into the innards of it or not, they're writing mostly Python code to build these AI tools.
And that's really been a wonderful and interesting thing to see.
So anyway, that was a long-winded thing about who am I, but yes, so I am the founder.
I was a CTO here at Anaconda for a while, sort of founding CTO.
And then I was CEO for four years.
And this year I stepped into the chief AI officer role really to try to help us explore and define what is the future of a company that's really been focused on Python coding for data science.
What does that future look like in a world that is obviously being rapidly transformed by AI?
Yeah.
Well, you're leading one of the main data science companies for the primary language for AI in the world.
So, yeah, it makes a lot of sense.
That's awesome.
You know, when we talked, I can't remember how many times ago, but one of the times ago we talked about bringing Python into the enterprise and sort of making it more acceptable for large companies and so on.
I want to show you a graph here.
I'm sure you're familiar with the TOB index.
Yeah, yeah, yeah.
Many people are.
But I think there's something interesting here that I noticed.
It just blew my mind.
And I just like to get your thoughts on it.
So a while ago, a couple of years ago, Python became the number one language on the TOB index, right?
But what's interesting is not just that, but it is more than double the second most popular language, more than double.
And so it's more than double as popular as C++ was number two, then Java, then C, then C#, then JavaScript.
The most popular one of those is more than double.
But here's, that's not the number that's actually most interesting to me.
The more interesting number is the derivative of that, which is the rate of change.
Python is growing at almost 9% year over year, where the others are like half a percent, a third of a percent, 1%, negative 3%, you know?
What do you think about this?
How's that sound with you?
Wild, right?
Well, I mean, you know, I guess, you know, congratulations, I'm sorry.
Because Python, we haven't decreased the number of warts by 10% year over year, right?
I mean, more and more people are learning this language, and there are some idiosyncrasies, and there is a complex ecosystem.
But, you know, the real story behind this is what they're not showing is the denominator.
And as I recall, TOB is based on a number of things.
It's a sort of a mixed model, right, of web searches, stack overflow, which I don't know how they adjust that given, you know, modern usage of LLMs and ChatGPT and copilot and things like that.
But it's a combination of all these different kinds of metrics.
And I know one of the criticisms of TOB has been that, oh, it doesn't tell the whole story, right?
But it certainly is a swag.
And the swag has been Python's been on the uptick, on the rise.
I think with the advent of, I guess, November, this month marks the two-year anniversary of ChatGPT.
The number of new people coming in to making software or doing deeper things with code than they could have done before is growing.
And so I think when we look at a thing like this, you know, this is the fun number.
So I actually, in my PyCon keynote when I announced PyScript, I sort of asked people this question.
How many software developers are there in the world?
What is actually anyone who knows anything about IT in the world?
Anyone who can, you know, plug in a server, knows how to boot, you know, boot disk, can write a line of SQL code, can, you know, fudge some Python or JavaScript or HTML together.
Anybody who can do anything related to computers, not stare at the screen dumbfounded.
What percentage of the population is that?
And the swag is something like 4% of the population, right?
Which in a world of 8 billion people, that's a lot of people.
But that's not a lot of people.
Imagine a room of 100 people, four of them know how to do anything with computers out of 100, right?
Maybe one and a half know about farming.
So that's even more terrifying.
But we live in a computational world and about 4% of the people of the world's population are involved in IT.
Now that's not, you know, normalized against developed countries versus developing countries and all this other kind of stuff.
But at the end of the day, you know, we would admit that there are something on the order of tens of millions of software developers.
But if we say we're going to open the doors to allow anyone to be asking a question of an interactive coding assistant to then be able to produce software, to maybe write a Kubernetes, configure a Docker file, Kubernetes YAML thing, whatever it is.
You are now opening the floodgates to a 25X number of people that can do code.
It won't be great code.
Actually, sometimes might be better code than a junior dev could do.
But nonetheless, the point is there was a lot of headroom that we're ignoring.
And I think a lot of Python's growth can be attributed to that.
And one of the biggest things that we found going to businesses and talking about using Python, especially for data science, was how many of them did not understand this concept of a data person who would use Python or R to do a data analysis.
For them, an analyst is someone who used Excel or Tableau.
And then coders are people who wrote code.
And they would lump the Python data science Jupyter notebook person in with the Java nerds.
And those are two very different kinds of people, right?
So I think this expansion and growth of these people who code Python as a way of getting some stuff done but are not software developers, that's going to push those TOE numbers even higher.
Yeah, I think so as well.
It's a great observation.
And there's been all these learn to code movements, trying to get kids to learn coding and stuff.
And I do think those are valuable.
I don't think it means we need 10x the number of software developers.
But I think having programming skills is awesome.
But I feel like LLMs and ChatGPT and so on, they're going to make a way bigger impact than if you took a scratch class in fifth grade, you know?
Yeah.
And I, you know, there's a, well, not to get too philosophical on it, I suppose.
But one of the, oh, can you hear me okay?
I thought my, how did my, yeah.
I don't think we need 25x more software engineers, right?
Just like we teach people math, we don't need 25x more mathematicians.
And we teach people English, we don't need 25x more authors.
But everyone should be able to author, to do some math, to think quantitatively about the world.
And with code, I think the important thing isn't, are you a scratch coder?
It's do you understand how computers process information?
And what is happening to your stuff, right?
And how you're interacting with these things.
It's really, I think that's kind of the weird moment we're going through where people really have to look at these kind of programming-like skills or knowledge of computers as a literacy or a life skill.
Again, it's like learning to drive.
Doesn't mean you're going to be an F1 race car driver.
There's only a few dozen of those in the world.
But everyone needs to know how to drive, right?
So there's something about this that I think is lost when we're teaching.
I think what happened is in the last 20 years, software development was in such demand.
And all of those software businesses took off so much that they made so much money.
So software engineers made so much money.
So everyone's like, I'm going to learn how to code.
So I'm going to these really sweet coding jobs.
And it turns out that's not actually the thing, right?
It looked like a gold rush, sort of.
It was absolutely a gold rush.
Yeah, absolutely.
Yeah.
Awesome.
Well, let's talk a bit about Anaconda.
First, Justin, maybe, I mean, you talked about your roles changing there, but just give us a sense of what is Anaconda.
I know there's a lot of people out there listening.
I'll throw it with another stat that blew me away.
The PSF JetBrains Python developer survey asks all the respondents, how long have you been programming as a professional software developer in any language, not just Python?
And the 50% of the respondents said less than two years.
Right.
So a lot of the people out there listening maybe don't even know what Anaconda is, even though it's very well known within the Python space.
Give us a bit about what you guys are up to these days.
Yeah.
So we started, I think, probably best known as the providers of the eponymous Anaconda distribution and the installers for the various packages.
And really our bread and butter is building out, you know, the Python packages, maintaining a kind of a curated repository and really selling access to that to commercial businesses that want to actually have a vendor back, vendor supported source of Python packages.
And for most Python packages, I mean, there's many people in the world who are very happy pip installing off PyPI.
Things work great.
But when you get into some of the more numerical or maybe GPU intensive packages, the way it gets built is enormously important and can sometimes be very, very challenging.
So when we started Anaconda over 10 years ago, it was actually very, very hard to get those pre-built binaries installed.
Now it's a little bit easier.
People are rolling a lot of libraries into, you know, these big fat wheels from PyPI.
And that can work pretty well in some cases.
In some cases, it fails catastrophically.
Right.
But what we do is we provide enterprise support.
We provide also just a validated and secure open source supply chain around these really important binary artifacts that then become deployed into Docker containers that become then the runtime for machine learning and data processing for, you know, very sensitive customer data and things like that.
So we have a model that's very similar to what Red Hat did for Linux, right, where you can get Linux for free.
You can run the free stuff.
You can go and pick up packages from the free community repositories.
But if you're really serious about a business runtime environment and you really want to have like, you know, a throat to throttle, so to speak, if something is not quite right, then you go and you go pay Red Hat for the annual subscription.
And so we have very similar business model around that.
We made the Conda package manager.
But to be very clear, the Conda package manager is an open source project.
So we put that into the open source and have a community around that.
The Conda Forge community is the package build community around that.
We host the repositories there, but those are free for everyone to use.
So we really have been, you know, from a business standpoint, that's a bread and butter working with things like Microsoft Excel and working with things like Snowflake to really embed polished Python runtimes inside those computational environments.
That's something we started doing a few years back.
This year, I think for the most part, people's experiences of Anaconda have not changed too much, just Conda packaging, whatever.
But there are a lot of things kind of happening behind the scenes, right?
So we did, for instance, the Python Excel stuff, which we'll be talking about later, is a huge thing that we're very excited about.
But then we've also been pushing forward on our perspectives on AI.
So we know that a lot of, like I said earlier, a lot of AI is built on Python.
A lot of AI relies on having the right packages and software alongside the models and whatnot.
And we have a particular belief that the models will get smaller and more people want to run these models locally or close to their sensors and their data.
They're not going to want to upload these into the cloud, or it's not going to be feasible because there's a lot of video streams from many different kinds of sensors.
And they're going to want to have a solid software stack to run these models that they need to update and fine tune.
And so really looking at ourselves as a provider of that level of the software stack for people, that's kind of what we're orienting towards.
So we released a product called AI Navigator, which people can go and use to download models.
We host the model repository.
So we have a curated set of quantized models that we're hosting.
And so people who, you know, one of the things that we got from our enterprise customers quite a bit was, hey, we like using your enterprise software package repository.
We love that it's, you know, has your stamp of security approval on it.
But do you have anything like that for models?
Because we just right now download stuff off Hugging Face, and that's kind of okay.
But like, you know, like we don't really know who quantized this.
That's running arbitrary code off the internet.
How could it go wrong?
And, you know, not to throw shade on any of that, because an open innovation is great.
But people do feel like, you know, we need something in between there.
So we have both our AI Navigator, which lets you run models locally.
It's similar to like if you use like LM Studio or something like that.
It's a nice way to sort of get all this stuff running locally.
But then you also get a, we have our model repo, which is kind of right now in an alpha stage, alpha beta stage for people if they want to run that on-prem.
They can then have an on-prem model repo, and IT can actually have a view on what's getting deployed in various places.
So it's a very similar kind of model.
We're just kind of responding to customer needs.
So there's a couple of products that we're building on the AI side.
This portion of Talk Python to me is brought to you by Sentry.
Code breaks.
It's a fact of life.
With Sentry, you can fix it faster.
As I've told you all before, we use Sentry on many of our apps and APIs here at Talk Python.
I recently used Sentry to help me track down one of the weirdest bugs I've run into in a long time.
Here's what happened.
When signing up for our mailing list, it would crash under a non-common execution pass, like situations where someone was already subscribed or entered an invalid email address or something like this.
The bizarre part was that our logging of that unusual condition itself was crashing.
How is it possible for our log to crash?
It's basically a glorified print statement.
Well, Sentry to the rescue.
I'm looking at the crash report right now, and I see way more information than you'd expect to find in any log statement.
And because it's production, debuggers are out of the question.
I see the traceback, of course, but also the browser version, client OS, server OS, server OS version, whether it's production or Q&A, the email and name of the person signing up.
That's the person who actually experienced the crash.
Dictionaries of data on the call stack and so much more.
What was the problem?
I initialized the logger with the string info for the level rather than the enumeration dot info, which was an integer based enum.
So the logging statement would crash saying that I could not use less than or equal to between strings and ints.
Crazy town.
But with Sentry, I captured it, fixed it, and I even helped the user who experienced that crash.
Don't fly blind.
Fix code faster with Sentry.
Create your Sentry account now at talkpython.fm.
slash Sentry.
And if you sign up with the code, TALKPYTHON, all capital, no spaces, it's good for two free months of Sentry's business plan, which will give you up to 20 times as many monthly events as well as other features.
And there's a lot of other exploratory bits of AI.
So we've added an AI assistant into our hosted cloud notebooks, and we've just actually added GPU support to cloud notebooks.
So if you go to amicom.com and you go create an account, you have actually access to a hosted cloud notebook solution that also has access to GPUs and has a chat assistant.
But the thing is that that's not, that can be a local experience as well.
So if you're running Jupyter locally, you have an in-situ, you know, chat assistant right there.
And that's been trained, that's our own fine tunes based on how people use Jupyter interactively, which is different than training Jupyter on a corpus of uploaded notebooks.
Those are actually very different kinds of things.
So those are kind of the new things we've been working on.
And then, of course, there's updates to various kinds of technologies.
Panel, we're doing, you know, dashboard building.
PyScript continues to get better.
And so, yeah, I'm probably forgetting a dozen other things.
But those are kind of the highlights of the things that we've been pushing on.
Yeah, yeah.
And you guys also did PyScript, which we'll talk a little bit about later, potentially, if we have some time for it.
What are your thoughts on this PEP 759 external wheel hosting?
You refer to wheels as big, heavy, binary things.
Oh, no, no.
So to be very clear, wheels can be very lightweight, but they can also be very heavy.
And in fact, what a lot of people who are not package maintainers, you know, I think most Python users are like,
the package install part of my workflow is the least interesting and oftentimes the most painful part of my workflow.
I really don't care.
I just want it to work, right?
And unfortunately, you know, that doesn't always go well because you end up having to get dragged into complexity.
And so we're going to get into some of the complexity here.
But for those who are interested, I did give a talk at PyBay just a month ago, I think.
And it's up on YouTube now.
It's called The Five Demons of Python Packaging.
And I try to lay out for people why it is that the why is Python so screwed up in terms of the Python packaging environment?
Can we just do what cargo does?
Or can we just do what NPM does?
Or why doesn't Go have this problem?
Or what, you know, like yada, yada.
And so I think there's a, I don't want to argue with people, but I want to share my context, right?
In that context.
Oh, this is it, right?
I'll put it in the show notes for people.
Yeah.
Great.
Yeah.
My context is that there are, if you go to the very beginning of the slide, I have a picture from Gödel Escher Bach, right?
The cover of the book, Gödel Escher Bach.
And it shows that this block in the middle looks like the letter G, E, or B, depending on which direction you're shining the light.
Many people may be familiar with this book and its cover.
And that's how I think of Python packaging.
I have the great misfortune of having wandered all five or six dimensions in my career.
But most people experience only two or three of those dimensions.
So for their perspective, it could just be this simple.
Or why don't I just do that?
I just homebrew my dependencies.
Or I just use RPM to install these base libraries.
And then I pip install these other things in a Docker.
And I'm done, right?
But what we have to do as maintainers and also as people who kind of cater to a broad tens of millions large user land is we have to account for all six of those dimensions.
And sometimes they're not obvious to people, right?
So in the case of wheels, to come back to the discussion about wheels and Barry's proposal there, the issue that many maintainers have with wheels, especially if they're maintainers of libraries that have a lot of C dependencies, is that you're stuck between a devil and a rock and a hard place.
And so you have to decide, do I bundle all these dependencies in?
In which case, I own the compatibility issues and I own the security issues that come with having bundled in a bunch of C libraries or C++ libraries.
If I don't bundle them in, then users are kind of stuck trying to install this thing, right?
And so what we find is that for some libraries, it's okay.
For other libraries, it's very difficult.
And the Python ecosystem, I think, ultimately still does not have a great solution to this.
And wheels, as you know, the way that the PyPA and the pip maintainers and other people we've talked to over the years, they really want to think of the packaging problem as a Python packaging problem.
And with Conda, because it was built, it was purpose built for the scientific Python ecosystem, we knew from the outset that our problem was bigger than Python.
In fact, most of our problem was packaging stuff that wasn't Python.
The Python bits were trivial almost, right?
But it's the, you know, what version of Clang?
What C++ ABI do you use?
What version of this do you link?
And what flags do you turn on when you invoke GCC here?
When you go and you compile something and all of that, not only are you including all the C libraries,
you're also inheriting all of the design, sorry, the configuration options of the build tool chain at compile time.
It's an enormously complex thing that ends up getting wrapped up into a single wheel, right?
So with Conda, these are represented explicit dependencies with feature flags.
And you can then sort of do this package sort of dependency solver, which of course is, you know, good and bad.
If it's, you know, the ecosystem is too big, the solve takes too long.
But then if you don't do that solve, then you just run into stochastic and irreproducible installations.
So what do you do, right?
So this proposal, but specifically about this proposal that Barry's put out there, this is, I think, meant to address,
and he works now at NVIDIA.
And people who've had to deal with GPU packages know that the CUDA libraries can be quite large.
They get pretty big.
And they are somewhat of a tax on the hosting infrastructure, on the CDN there for PyPI.
And so the limits that PyPI has imposed makes it difficult for them to kind of have increasingly larger packages and all these like nightly bills that they want to upload.
So this proposal is, can we split this out?
These RIM files.
And so we put a placeholder in place on PyPI, and then put the actual package over here, right?
Right.
If NVIDIA wants to ship a 400 meg pip installable package, let them host it.
Right.
Something like that, right?
That's right.
And so this gets to one of the demons I mentioned, which is that a repository is not the same as a distribution,
and it's not the same as an FTP site or a Dropbox.
These are actually very different things.
And I have not actually commented officially on this on the discourse at all.
I've had some private conversations with people, but I might as well, since you asked.
My thought is that this is not a bad idea, but the challenge is we are going to go down a path, essentially,
of having to solve the cap theorem.
Okay.
What I mean by that is if you view PyPI, like what is PyPI?
Is it a Dropbox where anyone could just upload whatever?
Okay.
But the problem there is if someone installs something today and they try to install again tomorrow or two weeks from now,
they're going to generally want the same kinds of things.
And if it's just a Dropbox, then no one is responsible for providing a stable snapshot of what points to what
and what is what even.
Because in the space of even an hour or two on something as large as PyPI, you can have updates.
You can have updates of versions of the different build strings.
All people can yank a file because, oh my God, I bought the build on that and so on and so forth.
So if you view it just as a Dropbox, that's okay.
But then all the work of consistency and reproducibility gets foisted onto the install tools, the client-side tools.
Whether it's UV, whether it's PIP, whether it's Poetry, PyM, you name it.
Hatch, PDM, Poetry, all these wonderful tools.
Anaconda, too.
I should put that out there, right?
Everyone is trying to solve this problem.
And the question is, is the repository host going to solve the atomic sort of state view?
Or is the client going to have to piece it together somehow?
And then the reason I mentioned the cap theorem is if you say, okay, we should pretend that it's somewhat of a stable repository, not just a Dropbox.
But as a repository, that means that there's a snapshot of things at a state in time, the metadata.
Well, okay.
But if you allow for some of these packages to be hosted over here, now you have a distributed database.
You have a distributed object database.
Massively distributed.
And NVIDIA, obviously, as a trillion-dollar company, can keep up a CDN.
Okay?
But they cannot avoid net splits.
They cannot avoid a backhoe in Reston nuking a fiber line somewhere, right?
You cannot avoid the kinds of things that happen that cause a distributed network database to suffer consistency problems.
So now someone building a Docker.
And when you're looking at something as important as the CUDA-oriented libraries, the RAPID libraries, these, like, really important foundational GPU libraries, people are pulling these to the tune of thousands and thousands per second.
So you have got to make sure you're consistent all the time.
Otherwise, someone's production Docker build falls back on an old version because they couldn't get the most recent one.
Or a time, I mean, in the best case, it times out.
It complains loudly.
The worst case, it fails silently and falls back.
And whatever client-side tool they're using then says, well, I can't get that, so I'm going to solve this way.
I'm going to solve this other thing over here.
They pick up an old version, and now you have, whatever reason, your model build deployment doesn't work, right?
Right.
Maybe you picked up a regression equivalent of a bug that you know is fixed in the new one.
You asked for the new one, but you didn't get the new one.
You didn't get the new one.
And so the point is, the reason I cite the cap theorem is at some point, a package hosting site like this has to decide, is it just a Dropbox?
Is it a repository?
Right.
And if it's the latter, then it has to offer an atomic and consistent, verifiable view of the metadata.
That's what with Conda, we have a thing called RepoData.json, and it is a big fat file, and it is basically the snapshot of the repository, and it is transactional.
So you get the whole thing, and then you can do the solve and say, I want these pieces, and then you go get those pieces.
So from a design standpoint, architect standpoint, it's not that complicated, but it is a different, it's a design difference.
Then when you think about pip installing off PyPI, it is eager and opportunistic, let's say, right?
So it goes, tries to install a thing, it grabs that, looks through it and says, oh, I need these things.
It goes and grabs those things.
And so over the course of a multi-second long or maybe in a multi-minute long install, you don't actually get a consistent view of the repository.
And so with this, this now says, really stresses the question.
I think what the RIM proposal does, it really forces the question of, is PyPI a repository or is it a hosting site?
Like Sunsite thought, yeah, FTP at Sunsite.edu back in the day, and you just go grab whatever and good luck.
And all of that complexity of consistency is then the responsibility of the client side tools to manage.
That is the design decision you can make, right?
Yeah, I hadn't even thought about it from a reproducibility science or even just old applications perspective.
That's pretty interesting to think about.
If I read this, Pep, I don't recall if it talked about a backup that would allow the PyPA to create some kind of snapshot that says, even if those mirrors went away, this is the reality of things, right?
I mean, it's one thing to say, well, let's let NVIDIA handle the 100 megabyte download request a thousand times a second.
But we got a copy of it, and if that fails, we can switch over to our version versus let's let them hold that part.
And if it fails, it's just gone.
And there's nothing but an empty RIM.
There's no wheel.
Right.
But consider this.
If I discover a zero day in one of those things, and by the way, these things are low-level libraries that touch kernel space things and things in the driver, and they touch memory, and there's all these things.
And there are real implications on this kind of stuff.
So let's say there's a zero day where I have some hack, and NVIDIA, because they were notified of it, they patched it.
But you have a fallback.
And if I somehow managed to block your ability to resolve or to access that, now you're still picking up the old stuff.
And you're building those into your Docker, right?
So it's not just availability.
This is why it's not just availability and fallback.
It is consistency.
So that when you push an update, it forces an update, right?
Right.
So when I said I thought there'd be some kind of backup fallback, in my mind, I don't even know that this isn't the pepper that it's addressed at all.
It maybe, I don't recall that it is, is before PyPI allows it to be listed as a new version, they've downloaded a local copy, and they've got the new one.
They're not going to serve it to you, but they have it.
You know what I mean?
Yeah.
It's going to be interesting to see if this gets accepted and what implications there are.
But on the other hand, the flip side is it's also scary that pip and PyPI have over $100,000 of donated bandwidth.
And if that donation ever stops, all of a sudden, out of the blue, we'd also be in a world of hurt, right?
And so if we could distribute that risk a little, which I think is the purpose of this, Pep, that's helpful.
Yeah.
I think it would be interesting to solve that problem.
I like to solve technical problems at the technical level and economic problems at the economic level, right?
And so conflating these two can lead to, I think, it muddles things a bit.
So the question is, what is a good design for a distributed, high-performance, but consistent and secure repository?
Well, that is traditional CDN.
I mean, it's not really that hard of a problem.
It's been solved many times by many different kinds of people, right?
Whether it's Windows update, Apple update, whether it's like what we do with Conda.
You put a CDN in front of a consistent sort of index, and you force that kind of consistent index, and you do that.
And that's okay.
That's what you do.
Now, how you fund that is a different question, right?
And so it could be we fund.
We just put all the money into the PyPA or some PSF delegate organization that goes and just runs a packaging thing, some consortium that people donate into.
I mean, $100,000 a month.
Yeah, I mean, look, the Conda repos cost more than that.
We ship a lot of binaries, right?
So I think the bandwidth costs maybe more than what you're citing, actually, for PyPI because it's much more popular in Conda.
But at the end of the day, it is something on the order of a few million dollars a year, I think, in CDN equivalent costs.
And when you look at how many people use it in the world and depend on it, there is that budget available in the world.
So the fact that we as a community don't know how to talk to the businesses that depend on it to get those dollars, that's our problem.
That's not really because businesses spend more than that on marketing parties, launch parties for random crap, right?
Yeah.
We have infrastructure that powers the world, and we as a volunteer kind of community of people who love Python can't figure out how to have a conversation with them to get a few more million dollars out of them.
That's our problem.
How do we get better at that?
Yeah.
Yeah, for sure.
Well, let's just go back to BitTorrent.
All right.
Speaking of companies that have some money to work with, let's talk Excel.
Let's talk about Excel.
Yeah.
Literally, it's the tool that probably processes the most financial numbers in the world, you know?
You know, it is ironic that you mentioned this now because you brought up TOB, and I would say Excel is the dominant programming environment in the world.
Yeah.
And Excel didn't make the list.
Didn't make the list.
Maybe it should.
I should go talk to the TOB editors.
If it's not the most popular programming thing, it probably is the most widely deployed database.
Yes.
It is the world's most popular database, the world's most popular computational environment, the world's most popular programming environment.
Yeah.
Because it actually was the last one of the things from the 70s and 80s with, like, end user computing and programming for everyone.
This was one of the last great tools, you know, the spreadsheet.
So normal people, muggles, could approach this and put computational things together.
This portion of Talk Python to Me is brought to you by Bluehost.
Got ideas, but no idea how to build a website?
Get Bluehost.
With their AI design tool, you can quickly generate a high-quality, fast-loading WordPress site instantly.
Once you've nailed the look, just hit enter and your site goes live.
It's really that simple.
And it doesn't matter whether you're a hobbyist, entrepreneur, or just starting your side hustle.
Bluehost has you covered with built-in marketing and e-commerce tools to help you grow and scale your website for the long haul.
Since you're listening to my show, you probably know Python.
But sometimes it's better to focus on what you're creating rather than a custom-built website and add another month until you launch your idea.
When you upgrade to Bluehost Cloud, you get 100% uptime and 24-7 support to ensure your site stays online through heavy traffic.
Bluehost really makes building your dream website easier than ever.
So what's stopping you?
You've already got the vision.
Make it real.
Visit talkpython.fm/bluehost right now and get started today.
And thank you to Bluehost for supporting the show.
But it has limited expressiveness.
Well, I don't mean that in a mean way, but just to say that people, you know, you don't really want to see hundreds of lines of Excel.
Like, that's kind of a terrifying thing, right?
Because it is a very much an immediate mode data transformation kind of language.
And so the Anaconda Toolbox for Excel is there to complement the Python support that just recently got added to Excel.
And that's GA now.
Yeah, I was going to say, let's start there, actually.
Sure, sure.
Because why does this exist?
Didn't Microsoft just add Python to Excel?
Yes.
So that's worth talking about, right?
So Excel on Windows has support for Python in the formula bar.
So if you have Windows and you run Excel, you can type equals PY in the formula bar and start punching in Python code, multiple line Python code.
You can refer to cell ranges, and it will spill your data frames into the grid.
You can chart things.
It's insane that we're here.
Like, it's amazing that works, okay?
Now, the way that works is it analyzes your code.
It actually looks at the range references and the cell reference and everything else, pulls all that data and your code, and it sends it over the wire to Azure Confidential Compute, which is an extra secure, extra lockdown version of Azure.
And it runs the code there on a customized Anaconda environment that we built for that.
So you have access to a lot of the data tools that you would expect, pandas, matplotlib, things like that.
So you do all that stuff, and then it comes back, and then it sort of renders in the grid.
So the computational environment doesn't have access to your full spreadsheet, and it also doesn't have access to the internet.
So there's no risk of data leakage and loss and things like that or tampering.
So in any case...
It probably also doesn't have access to your local file system if you've got other things to pull in or you want to write a Python file and import it as a module.
None of that, right?
Exactly.
And you've served as a wonderful straight man for me here because that is a bit of a limitation.
So the pluses are, number one, it's built in, and it runs the full-on Anaconda install on the Azure Confidential Compute.
So you have access to the bona fide packages and whatnot for doing data analysis.
The downside is there's no access to the internet.
There's no access to your local file system, things like that.
You have to sort of load those into Excel and then punch that data over.
So to complement that, we created this thing that we call the Anaconda Toolbox.
And so that is actually a WebAssembly-based plugin for Microsoft Excel, and it runs on the Mac version of Excel as well, and it runs locally.
So it is an Anaconda WebAssembly sort of environment hosted inside a plugin for Excel.
So that then has sort of richer access to things, but it is limited in that only those libraries that we cross-compiled into WebAssembly can work in there.
That being said, you can use sort of a pip install, install pure Python packages into that environment.
And you can also then, you know, one of the interesting things that we heard from people was that they, look, they could be a Microsoft shop.
They trust, of course, they trust Azure.
They trust Microsoft.
But they just have an IT policy where they're not allowed to sort of, they don't want the risk at all of the data leaving their local machine.
And this would run everything local.
It's just running everything local on your laptop or on your workstation directly inside the grid.
And we're working, I mean, the Excel team knows we're doing this.
They like seeing some things we're doing here.
And the scope here is that actually with this, we can explore features and run a little bit ahead of where the built-in Excel capability is.
So they have, they sort of have a way to sort of almost not quite A-B test, but see what kind of features are good and what features are not as interesting.
And they can then eventually over time, I think, roll those into the mainline Excel support.
Because when you have a product like Excel that's relied upon by so many people, you actually are limited in how fast you can move and in what things you can roll in.
Because once you put a thing in, you really can't take it out, right?
It's almost like a programming language, yeah.
It's a really important thing that people make billion-dollar decisions based on the values popping out of those cells.
So it's really important that that team is able to focus on the stability and have a very refined user experience.
For us, we can move a little faster, try different kinds of things.
So one of the things that we're really exploring and one of the things I'm hoping will come out of this Excel work is that we will see much more cross-team collaboration between data science kind of folks and business analysts and other kind of stakeholders.
who may themselves not be writing Python or not be very familiar with Python.
But using our toolbox, one of the things we have in there are simple ways to share code snippets and simple ways to share new kinds of data sources.
And to have really a lot of ways to make simple dashboards and visualizations that then essentially turn your Excel spreadsheet from not just a database and a computational environment, but into a full-on application deployment environment.
So for data scientists, you know, one thing I've heard a lot over the years from data science folks is that they turn into service providers for their teams where they're just being asked for new Excel outputs every single week.
Or every couple of weeks, they come back around and say, hey, that was great what you did with all your magic code stuff.
But can you rerun that analysis?
But this way and email me the, you know, email me the CSV of the spreadsheet.
And so with this, you can now deploy your code forward into a spreadsheet.
That's then the live forward deployed thing.
It can pull from a Jupyter notebook that you have running and hosted.
And then you actually are using this to deploy a live version of a self-service data environment analysis environment for your business stakeholders.
So create almost an API for your data that Excel is the front end.
You turn your notebooks into APIs and then your end users are using Excel, which is their native environment, as a way to hit that API to generate really quick visualizations.
We have a built-in, you know, LLM chat.
So you can ask for new kinds of this and tweak plots this way and that way.
And when you like what you've got, you can share it as a snippet to other people.
So that's a really powerful modality.
We believe that's a very powerful modality.
But this is the kind of feature which we want to get out there.
A lot of people play with it.
We'll tweak it.
And then once it gets really dialed in, then that's something which the Excel team might look at and say, oh, yeah, that's kind of what it should look like.
Now let's go and build this into Excel itself.
Let's go build this into native SharePoint and Outlook and other kinds of, you know, things.
So anyway, that's kind of the point of it.
But we're really super excited about all the kinds of innovation that can happen in this toolbox.
But we really rely on end users, right, to give us that kind of feedback.
What do you do at the notebook level to make it hosted and accessible as an API?
Is that just straight Jupyter or is there something more interesting?
Yeah, no, it's straight Jupyter.
But if you hosted that, and so all of this sort of to get access to the toolbox, you need to just create an Anaconda.
It's a free Anaconda cloud account.
And then the notebooks are going to be the ones hosted in your Anaconda cloud account.
And then the snippets are also there.
So everything is sort of shared through your Anaconda account, right?
And so then your friends who are using this can just reference that and drop that in.
And then they're able to use the code.
Yeah, that sounds pretty awesome.
Are you able to, you know, you said it's based on WebAssembly.
Are you able to create your own packages as WebAssembly things or pip install things?
You can pip install things.
Yes, you can pip install things.
Absolutely.
That's the, that's also the power of this is that you can kind of go a little nuts.
It is a little bit Wild West.
So definitely use with caution.
There are a lot of foot guns, but, but again, as a plugin, we can do more of that exploration
and find out where, where people, where the comfort level is, both for individual users,
as well as for organizations.
Right.
And, and we do have, I do want to plug that we have a webinar coming up.
It'll be exactly when it is, but we have a webinar coming up.
around using, using the assistant and all that.
And I should have been prepared with that information before mentioning it.
No worries.
I'll tell you what, let's put it in the show notes.
Send it to me.
Put the show notes.
Yeah.
Awesome.
So a question from Dennis in the audience, someone who it sounds like is really in the
know for these things, asking this sort of question.
Yes.
Okay.
So Anaconda Toolbox.
Let me read it for the people who are not watching.
Anaconda Toolbox for Excel, which kind of licenses?
That are needed to make use of this combination in an O365 environment.
Right.
So Office 365 right now, right?
Doesn't support the, the built-in Excel stuff.
Cause that's again, just for Excel on windows.
And so you can use Anaconda Toolbox inside there and the toolbox.
It is it's free, free to use.
We will have sort of some upgraded and premium features built into that, but you just need
to create an Anaconda cloud login or create a cloud account.
And then you should be able to use that.
So if you just have any version of Excel, you don't need things special.
The Office 365 version of Excel, right?
That's like the web.
That's the, the web hosted.
I see.
Got it.
And that's why it's.
I'm assuming, I'm assuming that's, that's what that's referring to.
I may be misunderstanding the question, but hopefully that made sense for Dennis.
Yeah.
I'm not, I'm not sure.
There's a lot going on with licensing and 365 for sure.
I bet there's people, I'm sure there are people whose job it is to just know the licensing.
Oh, sure.
Yeah.
And large organizations of a hundred thousand, you know, Windows users.
One thing to be clear is that for people who are in a corporate environment, your administrators,
your IT administrators will have to, it depends on what update cycle they're on, that they take
updates to Office and Excel.
So even though the, the Excel for Python or Python for in Excel feature is generally available.
Now your internal corporate environment may not be picking up that feature until the next
kind of iteration cycle when they, you know, the refresh cycle they do internally.
So that's just a caveat that I will put up there.
Okay.
And I may have missed this when you're talking about it, but do people need to have the Microsoft
Python Excel support to work with your toolbox?
You know, I, that's a question I should know the answer for.
I'm assuming I'm going to say yes, because you should have that support anyway, because
you should be using that.
But, oh, no, no.
I mean, actually, if you're on Windows, you should do it, but you don't have to have it
because it is a plugin that works on Mac and it works on the web as well, on, on Excel,
Office 365 on the web.
So it runs kind of independently, but we tried to make it as compatible as possible.
And one, one thing I forgot to mention really huge feature is that you can build your own
UDFs, right?
Like your ability to write a new function and then have that be available.
You can publish that as a function that isn't available in the, in, in the built-in list
of Excel functions.
And you can run that on a row and just drag and applies to everything in a row.
Like it's a very nice way to do some custom functions.
Yeah.
Okay.
It sounds really neat.
And I think WebAssembly gives you a lot of flexibility, especially since there's, as you
said, the web version.
Is that WebAssembly version based on PyOxid?
PyOxid?
Yep.
PyOxid.
Sorry, I'm mixing these together.
PyOxid or PyScript or like you're, I know you did a lot of work.
Yes.
It's PyScript and PyOxid, I believe.
I don't know exactly which portions are which.
It definitely relies on PyOxid for the WebAssembly runtime because we're using some of those
data packages, which are built against PyOxid.
Okay.
Yeah.
That's really great.
So what do you see people doing?
I mean, you described some scenarios, but you got any interesting stories of what some things
people are able to accomplish with this?
Oh, well, so not the toolbox specifically, but with the Python for Excel support.
Last week, we were in Chicago, Microsoft Ignite, and a gentleman from KPMG was talking about
how he turned hundreds of lines of very involved VBA for doing this tax preparation analysis.
He turned it into just a few dozen lines of Python code.
Right.
And so I think that speaks to the power of this in that what I hope to see is that many
more people in the Excel environment are able to use the great tools we have for data transformation
in Python.
But more importantly, that it lowers and reduces the friction between the data science
teams and their business stakeholders.
I think data scientists get trapped a lot in becoming kind of the data monkeys for folks.
Right.
This Excel spreadsheet is awesome.
Could you generate me one with the new data from today?
Because now we've got more traffic.
Right.
Or we run the thing or whatever else.
And what I hope actually that maybe the deeper, more transformational thing is I hope it creates
more interesting spreadsheets that causes all of these business users to be thinking, to have
their eyes open about how much more interesting ways there are to think about their quantifiable
problems, to run what if analyses, to slide a slider bar and say, okay, I want to see this
weekly, monthly, yearly.
I want to align to, you know, week starts or I want to start to calendar years or whatever
else.
Simple snapshotting kinds of things, which when you are, I think, a very, very experienced
Excel person, you know you can do it, but it is a very involved process.
It's like writing machine code.
Right.
It's very involved.
And so with this, you can just say, oh, with three lines of Python, I've now transformed
my data in bulk.
It's vector oriented and array oriented, data frame oriented.
And I think the more people think about that and the more they realize how easy it is to
do pivot tables with just switching two or three parameters in a couple of lines of pandas
or polar's code, like mind blown.
Right.
As opposed to clicking around on UIs all the time.
So I'm really.
I think it's going to be a gateway.
Yeah.
I'm really hoping.
Yeah.
I think the way that Python has kind of brought people who didn't see themselves as data
scientists into the data science realm and eventually they're like, but I'm just going
to work in notebooks instead of my other tools or whatever.
I feel like this could have a similar effect.
You're like, this is really cool.
I didn't know we could do this.
And then, so this is all Python.
Yeah.
That's all Python in the back end.
Well, maybe we should just do that directly.
You know what I mean?
Sort of work, get their feet wet and move, move into that direction.
So, yeah, yeah, I'm trying to get my folks here to get those links across to you.
So you can put those in the show notes.
Oh, perfect.
Yeah.
So I think it's going to have that kind of interesting effect.
The reason I brought up, I brought up this eight of the biggest Excel mistakes of all time.
There's all these different articles of, right.
You know, weird, weird things because, you know, for example, in my five bugged the wrong
phones because there was some formatting error that auto filled or, you know, we had to change
the name of a gene because it kept getting marked and all this random craziness, right?
Right, right, right, right.
So I think having Python available, because to me, Excel feels like the world's most insane
non-visible set of go-to statements.
I go here, then I go to that cell, then I go to here, then I go over there, and then we do
this.
And then, but you can't look at the spreadsheet and know that that's what it's doing.
Right.
But with Python in there, you have a much more structured way of thinking about your
data.
You're not forced into 17 interconnected go-to statements.
Yeah.
And you reminded me of the thing, which I, yeah, I said before, I just forgot to mention that
if you put more of the business logic into the Python code, well, guess what?
You can check in Python code.
Yeah.
You can diff Python code, and it uses variable names and variable references.
And if you do a little bit of hygienic approach to this, you set your variable references to
cell range to the top, then you manipulate the variables, and then you put the outputs down
there.
And now you really have very clean business logic you can follow.
Not to say that Python doesn't have its warts, of course.
I'm not some like, you know, whatever.
I see, I know how complex a Jupyter Notebook can get, for instance.
But at the end of the day, you're absolutely right that Excel is at the same time, both
so functional, right?
It is a data flow language.
It is immediate mode, dependency graph oriented, you know, in the grid.
A lot of good things about it.
Reactive, live, a lot of great things about that model for normals, for normies, for muggles,
whatever you want to call them.
People who are not imperative iterated state machine coders like we are, right?
But there's a place for that too, right?
Because you're absolutely right.
People will have these like weird linkages between different bits and pieces when what
they really wanted was a couple of named references and then some iterative logic or imperative
logic on those things with a branch statement somewhere.
You know, a couple of for loops, nif then statement can go a long way to simplifying very complicated
data flows.
Yeah.
That and vector math rather than copy the formula, drag it down 20,000 rows.
Right.
Why is this?
They warn you now.
At least they warn you again when like you're off by one and you forgot your minute of value.
There's like a little yellow triangle.
Okay.
That's good.
Yeah.
Nice.
All right.
Well, let's, you know, let's talk about a couple other things while you hear that you
all are into.
We just, there we go.
We just had Fabio drop in and he did a lot of the work.
I've had him on the show at least once, maybe twice to talk about PyScript.
Do you want to give us a PyScript update?
What is it for people who don't know?
I mean, they've been just, yeah.
They've been.
Micro Python, by the way, this is, this is huge right here.
Yeah.
Like it just works.
Right.
Yeah.
Tell us about it.
Well, so when we first released PyScript, it was, it was a sort of proof of concept.
Like, oh my God, you can, with doing some like interesting things, you can now just be writing
bracket, Py dash script inside HTML and be executing first class.
But we were running on Pyodide, which is a full on CPython build.
And it can then import things like NumPy and Matplotlib.
But, but it was kind of heavy to load.
It was a lot.
Right.
It was more designed for things like Jupyter light.
These were like, we're going to load up a big notebook and we're going to do awesome.
Awesome.
It's zero install.
Right.
It's, it's like you literally can just run everything in the browser without installing
anything because it's really downloading everything into the browser.
Right.
Yeah.
But it's, which is fine if you just start up once, but if you're trying to build a consumer
facing web app, it might be way too heavy.
Exactly.
It's not really a replacement for that.
So what we did most recently, number one, we added MicroPython support.
MicroPython is less than 80 kilobytes or so, no, maybe 300 kilobytes.
Now PyScript and MicroPython together is like 300 kilobytes and it starts in under a second.
So now you really can use Python instead of JavaScript to go and do things in the DOM.
So we have full DOM support.
You know, there's a native web API to manipulate the DOM and it supports web workers and async and
blocking calls and native storage.
So you can actually use the MicroPython bit and that's where the bracket MPY dash script and
that loads at the MicroPython environment and you can now be then loading the full Pyodide
PyScript in the backend and as an asynchronous sort of web worker.
So it's really an interesting thing that is, you can do a lot of interesting things with
it now, I think.
And we have experimental support for R. So we've not left our friends in the data science community
behind.
So that'll be great.
And, you know, we have some basic LLM and AI demos and there's people working on running
this on microcontrollers.
And so you can go manipulate, you know, embedded devices and everything.
So it's just a fun, fun thing.
Community is building interesting things at PyCon.
Lukash gave a really interesting talk, show how to do like 3D, like WebGL kind of stuff
with micro or with PyScript.
So I would say just, yeah, we're, we're sort of right now, you know, we have PyScript.com
where if you want to build things and share them more easily, that's great.
But if you are just want to use this as a technology, you totally should.
He's like, just take it and play with it and make little things with it.
Now there's a weekly calls, I think community calls that we do just join
and hop in on the discord and just get involved.
I think it's a really fun thing.
Yeah.
I really, I'm very excited about it.
I would love to see something like a view or a react just where just here's your front
end and you get to write it in this language you all love and already know.
I'm not necessarily hating on JavaScript, but it's not.
It's okay to hate on JavaScript.
Yeah.
I'm not intent.
My thought more is you're already working in one language.
Why do I need to do a second language just because of the place in which that language
executes is so dramatically limited, right?
It's the whole reason that node became a thing is we're already doing JavaScript.
Can we just keep doing JavaScript?
That's right.
Well, for Python people, it's just reverse that, right?
Right.
And there's a lot of really nice frameworks for front end stuff.
And the nice thing about PyScript is that it is pretty easy to use the JavaScript bridge
to call to all of those things, right?
What we don't have is a Python wrapper around those things.
So you can keep staying in the Python language.
Yes, exactly.
You have to use little proxy objects.
But for the most part, it's pretty nice to, like some on the examples, the 3JS examples,
some of these other things show how you can manipulate the JavaScript objects directly.
And we're just looking for more people to add interesting things to it.
But I agree with you.
Something that is like a Vue.js or React kind of thing that's natively PyScript would be,
I think, really unlock kind of that next phase of community growth and developer excitement.
Yeah, yeah, yeah.
It feels like the notebook in the browser deal is almost nailed.
Right.
But the, I'm going to replace my React front end with a Python front end, that's probably
the next frontier.
Yeah.
Maybe what I ought to do is I ought to put a bounty up there for someone to build a PyScript,
PyScript React thing embedded inside a Wasm object or Wasm container on the app protocol
and just put like a $20,000 bounty out there and see who gets there first.
Because I think that would show us how it could get done.
There are some things in decentralized web, these frame objects and whatnot that are there
to put little applets in the, on chain.
And I think we're, maybe we just, people just need a little kick like that.
Yeah, that would be amazing.
Right.
Yeah.
There was the whole keynote.
There's been several versions, you know, Carol Willing gave one of them.
Russell Keith McGee gave one sort of about, there's the few places that are really important
in computing that Python doesn't really touch.
And it was kind of mobile and web front end.
Right.
And so that would take down one of those two, which would be pretty amazing.
And maybe indirectly somehow find its way to mobile if it could be on the web, you know?
Yeah.
React Native is how a lot of people are doing the mobile development.
So if you have a wrapper for React, like that should, that should be there.
Right.
Yeah, exactly.
That'd be wild.
Yeah.
Awesome.
Okay.
Let's talk.
You got a few minutes to talk to Blue Sky real quick before we wrap things up?
Yeah, I do.
Yep.
You have a really interesting profile here on, I'll certainly put that into the show notes.
I am a new Blue Sky.
I just created an account last week.
Finally, I was thinking, you know, already I'm on Mastodon and I'm kind of on Twitter and
I've just got a lot to, I've got a lot of email addresses.
I kind of got enough, right?
But really recently, a lot of people have been moving from the tech space to Blue Sky.
And I'm like, you know what?
I had two thoughts.
One, like, I'll just create an account and see what it's like over there.
Why not?
That was thought one.
Thought two is, I better go there before somebody steals like the podcast handle on my name and
stuff, you know, like that.
Because that happened on Mastodon before I got there.
I'm like, oh, maybe not.
So, yeah.
So, I now have, I now have at mkennedy.codes as I'm here officially, right?
Right.
But yeah.
So, I'm really, I'm surprisingly delighted by it.
So, maybe.
Good.
I've seen you talking about a couple of projects and different things.
So, yeah.
You want to riff on that for a minute?
Yeah.
So, I know you're writing a lot about it, right?
You just did an article or something on it.
Oh, no, I haven't yet.
I've been meaning to.
This is the Thanksgiving post-tryptophan induced haze.
I might go and just bang something out.
Okay.
But I should tell my story, I guess, and my interaction with this ecosystem that, you know,
obviously, I think most people know me for my engagement in Python and Python, PyData,
Anaconda, all these kinds of things.
But for about eight years now, I've been involved in the decentralized web community in one form
or another.
I go to some of the camps that the Internet Archive puts together.
And I funded some projects around this area.
And years ago, I started funding a project called Beaker Browser, which is a decentralized
web browser for looking at local, it's a local first web browser that was imminently modifiable.
And then you would then use some kind of backend data transport like IPFS or HyperCore, DAT,
whatever kinds of things.
And so you have a very different approach to building websites, building web apps when you
have this data decoupled from the view, right?
Ultimately, I had surmised that a lot of the crappiness of the current internet and social
media apps and all these kinds of things was due ultimately to a flaw in the web itself,
which is the client server model.
Intrinsically dumps user data.
And from a software architecture perspective, what we might say is that we take an MVC architecture
and we split the view model and we put the view model out here, but we put the business
logic in the model over here and it's all owned by a trillion dollar tech company, right?
And so all of us that have to pay...
They observe the heck out of it as the data flows.
They observe the heck out of that and they sell those observations and they profit handsomely
from it.
But then it also leads to all sorts of...
There's a dark shadow to all of that, right?
Which is not good.
From a civil libertarian as well as from an entrepreneur, from a tech innovator perspective,
I don't like any of that.
So my investment into these decentralized web technologies were fueled by this realization
that I had.
That we had to really rebuild internet architecture from the bottom up and how we build applications,
period.
So that you can actually draw a thematic line from where my investments and things like
Beaker Browser to us supporting at Anaconda development of tools like PyScript and Beware,
Russell and Keith McGee, right?
Empowering end users to build applications and permissionlessly and as easily as possible,
share them with other users.
So we have a lot of innovation and creativity and joy ultimately in this creative space that
computing actually should be.
So ultimately Beaker Browser didn't work out as a company, but the guy who was behind it spent
four years, I mean, I funded him for those four years, doing a lot of experiments.
And what does decentralized Twitter, decentralized Reddit, decentralized Facebook, what do these
kinds of like local first experiences look like?
What is the right design for a protocol to do?
Like, you know, because he worked on secure scuttlebutt and these gossip networks, like
Nostra, like what Nostra sort of has.
And then like, what are the things where we have to centralize?
All of those learnings kind of got wrapped up into then what is now app protocol and Blue
Sky.
So he got hired in by Jay, who's the CEO of Blue Sky to go and build the, what is now the Blue
Sky app?
And the app protocol is the result of the Beaker Browser guy, Paul Frazee, working closely
with, you know, people like Jeremy and others that are the core devs at Blue Sky.
And so that's kind of my connection to this ecosystem.
So I'm user number six or seven, I think user number six on the network.
And I'm a big, huge proponent of this stuff.
So that has like no formal intersection with my work in the Python space.
It's just another aspect of technology that I'm very passionate about.
But both are actually connected thematically in the sense of empowering end users.
Actually, the Python bit, PyData, the Excel bit, and then the Blue Sky bit all connect in the sense of
empowering people, regular humans to use computers to the best, to making their lives better.
Whether it's asking more interesting questions of the world, whether it's being able to then share
and deploy the things they build with other people, whether it's, you know, reaching out to more and more
people, Excel has a billion users or something like that, 700 million users.
Right.
Meet them where they are.
Yeah.
Right.
And then with Blue Sky, it's how do we kind of go and like just have a different way of people
connecting to each other on the internet, being able to make interesting things
and really share in a spirit of collaboration.
And so one of the really important things about Blue Sky is that the way the moderation system works,
all those block lists and all those kinds of things that people have.
You know, I'm an old school internet guy.
And I remember if you were on Usenet, you would have a thing called a K-file.
It's your local kill file.
Right.
Which is people I just don't effing want to hear from because they're obviously idiots.
And your readers, news readers would respect that.
Right.
And so something that Paul and I talked about years ago was a social K-file would be a way
to have a social group be able to really just disincentivize and lock out the bad faith interactions.
Right.
Now, of course, you could go too far with that and just create a little echo chamber for yourself.
But there is a lot of space between spammers, trolls everywhere, spamming us with like crypto
spam and just like total echo chamber.
There's space in the middle.
Right.
So I think what Blue Sky is demonstrating with the shared block lists and things like
that and people just being able to mute things built in the UI.
Those are the kinds of tools we can make available when the company and the technology isn't incentivized
to create more angry bullshit sort of interactions and engagement.
So the algorithms don't promote that and push the heck out of it to get engagement.
No, the default Blue Sky algorithm is just chronological feed of following.
So if you don't want to see somebody's stuff, don't follow them.
You know, if you go to some of the other feeds, there's more algorithmic stuff there if you want to have it.
But by default, it's just whoever you chose to follow.
And if you don't like what they say and you know them, you should engage with them and say, hey, man, I don't agree with that.
Like, let's talk about that.
Right.
So I think this is...
Or unfollow them and just...
Or just unfollow them.
It's like, you know what?
They talk too much about politician XYZ.
I don't want to hear about that.
Right?
It's a very simple approach.
I need a space where I don't want to hear about that.
Yeah.
One thing I'll give a shout out to help people get started if they're interested in is they have this cool idea called starter packs.
Right.
And I created one called Python Personalities.
And you're on here, Peter.
So if they follow the starter pack, they'll automatically follow you.
But there's click follow and you get 60, 70 Python, nice, engaged people to follow.
And if you want to find other starter packs, there's blueskydirectory.com.
That's right.
Blueskydirectory.com.
There's 60,000 or so of these directories.
Yeah.
And you can search here.
You can say, I'm interested in Python or I'm interested in motorcycle or whatever it is you're interested in.
Right.
And there's AI.
Yeah.
I saw somebody have a starter pack called Friendly Weather Scientist Using AI.
It's very specific.
But if you want that group, there you are.
All right.
Let's close this out with a real quick bit of real-time feedback from Fabio from PyScript.
Oh, OK.
Yep.
There's a framework called PuePy on top of PyScript that is native and reactive.
Very early, though.
Yes, I had the guy on.
I'm sorry.
I don't remember the first name of the guy.
But I had the guy behind PuePy on.
And it looks really interesting.
I'm hopeful for it.
But I'm not necessarily sure yet that it's the answer.
And then Fabio also says, we're also working on the invent framework.
That is not really comparable to React for you, but in that direction.
I just love his YouTube avatar.
You said, well, hold on.
We should go to his YouTube.
Look at that.
This looks like an amazing picture from Halloween.
It's a very serious business profile.
Right.
Yes, Fabio's Fabio's partner is a world championship winning sort of body painter.
And so he has those.
He does the photography.
So that's why that's not just a random thing.
It's kind of related to his family stuff.
Yeah.
But it's kind of hilarious.
Awesome.
All right.
Well, I suppose we're probably out of time, Peter.
But it's always delightful to talk to you and so many things.
Yeah.
Well, thank you so much for having me on.
This is a lot of fun.
Thank you.
Yeah, you bet.
And I'll put the links for all the things we talked about in the share notes.
Let's leave it with a closeout for the Excel thing.
People want to get started with that.
What do they do?
Go to anaconda.com slash Excel or just go to your Excel.
Again, Excel for Windows.
Just type in equals PY.
See if that works.
And then for the Anaconda Toolbox, you can just also go into Excel plugin finder and you
can find it there.
Or you just Google Anaconda Toolbox and you'll find the install instructions there.
So definitely check it out and give us feedback on it.
Awesome.
Thanks.
See you later.
Thank 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.
Take some stress out of your life.
Get notified immediately about errors and performance issues in your web or mobile applications with
Sentry.
Just visit talkpython.fm/sentry and get started for free.
And be sure to use the promo code talkpython, all one word.
And this episode is brought to you by Bluehost.
Do you need a website fast?
Get Bluehost.
Their AI builds your WordPress site in minutes and their built-in tools optimize your growth.
Don't wait.
Visit talkpython.fm/bluehost to get started.
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.