When you think about the power of Python, the clean language or powerful standard library may come to mind.
You might certainly point to the external packages as well.
But what about the relative ease of picking up new libraries or even parts of the standard library?
Documentation plays an important role there.
And the tools in the Python space for building solid documentation and even publishing articles and books involving live code are huge assets.
In this episode, we have Paul Everett, Radian Gedem, Chris Holdgraff, and Chris Saywell to update us on Sphinx, Mist Parser, Executable Books, Jupyter Book, Sphinx Themes, and much more.
This is Sock Python under me, episode 354, recorded January 19th, 2022.
Welcome to Talk Python under me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.
This episode is brought to you by SignalWire and Tonic.ai.
Please check out what they're offering during their segments.
It really helps support the show.
Transcripts for this and all of our episodes are brought to you by Assembly.ai.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/Assembly.ai.
Pradyan, Paul, Chris H., and Chris S., welcome to Talk Python to Me.
It's great to have you all here.
Good to be here.
Thanks for doing this, Michael.
Nice to be here.
Thank you.
Yeah, absolutely.
Happy to be doing it.
I think talking about documentation and all the static site stuff and book generation stuff that we're going to talk about is going to be super fun.
You all are at the center of various fulcrums of that throughout the ecosystem.
So it's great to have you here.
Great to be talking about that stuff.
So let's just start really quick with a quick introduction and then what you're up to these days.
Paul, you're a regular here, so you want to go first?
Sure.
I'm Paul Everett.
I'm a JetBrains developer advocate.
Big fan of the show.
Big fan.
Total fanboy of the other three people here.
I've got all kinds of stories about where I was when I found out about Myst and the parser and desperately wishing I could join Pradyen and all the things that he's doing.
And I will add big, big fan of Carol Willing.
And when I grew up, I want to be Carol Willing.
And you're still at JetBrains?
Still at JetBrains.
Right on.
Keeping the PyCharm flowing.
Right on.
Pradyen, how about you?
I work at Bloomberg, although not what I'm going to talk about today is related to work.
Software engineer there.
Work on the bathroom infrastructure team.
I am a maintainer on PIP.
I have written a Sphinx team for two, depending on how you count the second one.
And I'm involved in a bunch of sort of various efforts around Sphinx at this point.
I've sort of made myself comfortable in these spaces and sort of made my way into the various discussion forums, I guess.
Yeah.
Fantastic.
With me, I guess, in this topic.
Awesome.
Well, welcome.
You seem to be the emergency maintainer of many open source projects, like Live Reload.
Yeah.
I have a mild issue of not knowing when to stop.
That's good.
All right.
Chris H.
Yeah.
So my name is Chris Holgraf.
I'm the director of the International Interactive Computing Collaboration, or 2i2c, which is a nonprofit that runs cloud infrastructure for interactive computing and the Jupyter ecosystem and the sort of surrounding ecosystem alongside of it.
I'm a little bit of a lot of research and the Jupyter ecosystem.
I'm a little bit of a lot of the Jupyter ecosystem.
I've worked a lot on Jupyter Hub, which serves multiple Jupyter sessions via some kind of centralized cloud infrastructure.
I also work a lot on the Binder project, which focuses on more scientific reproducibility and shareable computing environments in a kind of cloud agnostic and pretty flexible manner.
Yeah, that's fantastic.
For people who don't know about Binder, that's basically if you are at a GitHub repo or some published notebook that's not interactive, you can click that and it'll fire up a little environment where you can go and explore the notebook for real, right?
Yeah, exactly.
And so a lot of these things are kind of surrounding this general topic of like scientific communication, scientific reproducibility, bringing those kind of like data workflows and facilitating them with software development, which is related to a lot of the stuff we're talking about today as well.
Yeah, fantastic.
You also have worked on the MIST project, right?
Yes, yeah.
And one of the projects that I'm focusing on right now, along with Chris S and a few other collaborators, is called the Executable Books Project.
And this is basically an attempt at improving the state of open source kind of community-driven tools in the Python ecosystem around scientific communication and building a lot on top of the Sphinx ecosystem, because there's a lot of good material there to work with and a lot of improvements that can be made that'll benefit the broader Python community as well.
Yeah, yeah, very cool.
Looking forward to talking about Jupyter Book as well.
That'll be fun.
Chris Siewel, you're back.
Tell us about yourself.
Yeah, so I work in the Executable Books.
I guess essentially my kind of focus is on making the best tools for scientists to make open reproducible science.
So I work 50% of the time here in Switzerland at EPFL on a package called ADA, which is a Python workflow engine for running simulations, orchestrating simulations.
And then I work the other 50% of the time in executable books on Mist and Jupyter Book.
Yeah, that's really fantastic.
Is any of your work in Switzerland, does it have to do with CERN or other projects?
No, not to do with CERN.
It's an EPFL in a group on materials discovery.
Yeah, fantastic.
Let's start by talking about Sphinx.
So when I think about Sphinx, I think about Python documentation.
So who wants to sort of set the stage for Sphinx?
I mean, I guess it does say the Python documentation generator, but it does more than that as well if you wanted to.
So guys, what is Sphinx?
When do I use this?
What's its value?
It's been around for a long time.
I know that much.
Let's do a round table.
I'd love to hear everyone's elevator pitch.
Yeah, exactly.
What's the elevator pitch for Sphinx?
I can start with sort of how I got into Sphinx and then maybe how I use Sphinx now, which is a little bit different from how I initially used it.
I think that a lot of people, so Sphinx has been around for a really long time and it's a really powerful tool for documentation.
And a lot of people use it alongside of their software projects that they work on.
So my first introduction to Sphinx was via, it was actually a neuroscience analytics package called MNE Python.
And we needed documentation to describe, you know, the APIs and the functions and the classes and things like use cases and examples.
And so one of the really useful things about Sphinx is that it has an inherent extensibility and a lot of flexibility so that you can both generate like narrative documentation with it, but also include programmatically generated documentation, API documentation, and that kind of thing.
So it lets you kind of like more seamlessly merge together code documentation or documentation embedded within code and your more kind of traditional narrative examples, tutorials, that kind of a thing.
I see. Almost like a wiki plus an API documentation generator in one.
Yeah. Plus that's been around for a long time and with an inherent extensibility.
So a lot of different sub communities have kind of built out their own community specific documentation that builds on top of the kind of basic Sphinx building blocks.
Sure. I bet the scientific community has got a lot of specializations.
They're like, we need to be able to express stuff like this, right?
Well, so that kind of gets me to the second part of what I was going to describe, which is I think over time, and this is one of the inspirations behind Jupyter book to some degree, is the realization that like technical and API documentation is also really useful.
Well, I should say the things you need to build for really good technical and API documentation are really useful for other kinds of use cases as well.
And so I saw some other groups in the scientific ecosystem.
There's a really interesting one called Simpeg, which I think is just S-I-M-P-E-G dot X-Y-Z.
I'm pretty sure that's what it is.
And they basically built out a whole geospatial analytics tutorial and sort of documentation resource just built on Sphinx.
And so for me, seeing that, it kind of unlocked an aha moment in my head to realize that you could also use the same documentation engine for documenting lots of other things, not just software packages and things like that.
Technical documentation is quite generic and overlaps quite a lot with like scientific documentation and scholarly documentation.
And so that's the space that we've been exploring over the last couple of months and years.
Yeah, fantastic.
And a lot of the outputs are super flexible.
It outputs HTML, which you might host on somewhere like Read the Docs or Netlify, but also LaTeX, which is really important for publications and EPUB for eBooks and whatnot.
So pretty cool.
I think Sphinx is documentation generated written in Python, primarily intended for technical documentation with the ability to sort of intertwine narrative documentation with auto-generated documentation that picks up things from your code.
Right.
Yeah.
And this whole thing is combined with the ability to have a variety of output formats, as well as a variety of extension points within the tooling to extend basically every aspect of building that documentation.
Interesting.
Yeah.
So for example, testing the code snippets that you might have in your documentation.
Yes.
Or doc strings or something like that, maybe.
Yep.
So that is doc test and that's baked into Sphinx and Python's documentation, which happens to also be written in Sphinx.
Okay.
Interesting.
By Sphinx.
So there's a lot of capability and power hidden underneath the shell of Sphinx.
And as Chris was mentioning, there's really extensive customizability here that you can then take and specialize it to your specific use case.
And that's sort of both the power and, you know, there's a con to that, which is, hey, you got to maintain this and you got to keep this functioning and stuff.
But yeah, it's a really powerful documentation generation tool that is perhaps a little too powerful for its own good.
Very good.
Yeah.
So docs.python.org is generated by Sphinx, huh?
Yes.
Fantastic.
All right, Chris.
Yeah.
I think the other point that I wanted to touch in is one of the brilliant points there on the Sphinx site is the cross-referencing capability is just second to none.
You know, you can reference inner page, you can reference cross-page within your own documentation.
But also, and one of the things that's really helped to build on Sphinx is the Read the Docs community and the work they're doing so that you can reference any other site that's built on Read the Docs as well in a really nice way.
Yeah, that's something that really surprised me when I learned about Sphinx is, you know, give a quick shout out to Paul.
Paul wrote a course that we hosted over on Talk Python, generating static sites with Sphinx and Markdown, which is really, really cool.
And one of the things that surprised me is when I think about creating multiple pages.
So, for example, if I'm on GitHub and I want to have this part of some read me here, point to some other read me or some other Markdown, I just go in there, I type, you know, here's the relative path over to that thing.
And I come up with the text that goes there.
Sphinx allows you to have kind of an index into all the sub elements of the page, not just the pages, but like parts of the pages, you know, headers and whatnot.
And you can link to them by name, right?
And so if for some reason you change the title of a header, your A tag text that you are linking to will change, which is pretty awesome, right?
Exactly.
Yeah.
And also, enter Sphinx, right?
Which is a way to expose those endpoints, not those endpoints, those index points across domain or across project, right?
So I could reference to something on Python in my documentation, specifically by a reference point, not by URL, which is pretty excellent.
And I think that's a big part of why Sphinx is as adopted as it is, by the fact that interSphinx exists and the fact that you can very easily cross-reference bits in other parts of the ecosystem, as long as that part of the ecosystem is in Sphinx.
Yeah.
As the interSphinx file generators, right?
Like in theory, other ecosystems could, or other tooling could generate it as well.
But yeah, I think that is quite capable if the fact that it's in restructured text has some fun interactions with all the linking syntaxes that exist, but it's genuinely very powerful, as I said.
Yeah.
So let's talk about that for a little bit, because when I thought about Sphinx originally, I always thought about restructured text.
And restructured text is kind of funky.
I don't know.
I just have a hard time getting used to it.
But all those formats and whatnot, it takes some getting used to, right?
You've got, let me see if I can find an example we can pull up here.
You know, things like dot, dot, image, colon, colon, some other thing.
And then, you know, sort of almost like a YAML style.
And to me, when I'm writing, I feel like, wow, I would just much rather write Markdown and just blaze through this and write it nice and clean.
And I'm willing to give up a little formatting or something to allow me to live in a simpler world that doesn't require so much stuff.
So traditionally, restructured text has been the way of the documentation through Sphinx.
It's also been like the way that you put your information on PyPI and describe it there, right?
But the PyPI.org version moved over to at least support Markdown.
And through some of the work you all are doing, Sphinx now has an integration layer with doing everything in Markdown as well, right?
You want to talk about that maybe?
Yeah, I think so.
As Preza mentioned, Sphinx is just incredibly powerful.
But it's trying to harness that power and make it not overwhelming to non-technical users.
For people who want it, it's brilliant and you can do everything under the sun.
But trying to sell it to the masses, as it were, and trying to make it as easy to use as possible for simple use cases.
But then having that extensibility there is, I guess, kind of what we've been looking at in executive books.
And with this, with the Markdown, most everyone now knows about Markdown, Common Mark, how to write.
Right.
We've got GitHub and Stack Overflow have basically forced the software development community to understand it, right?
Exactly.
Or whether people love it or hate it, it's there and you know it.
So being able to just copy and paste things from GitHub or Stack Overflow or just write something that's quite intuitive to write.
That's what we're really trying to hide some of the intricacies of Sphinx.
Make it more user-friendly on the front.
This portion of Talk Python to me is brought to you by SignalWire.
Let's kick this off with a question.
Do you need to add multi-party video calls to your website or app?
I'm talking about live video conference rooms that host 500 active participants, run in the browser and work within your existing stack, and even support 1080p without devouring the bandwidth and CPU on your users' devices.
SignalWire offers the APIs, the SDKs, and edge networks around the world for building the realest of real-time voice and video communication apps with less than 50 milliseconds of latency.
Their core products use WebSockets to deliver 300% lower latency than APIs built on REST, making them ideal for apps where every millisecond of responsiveness makes a difference.
Now, you may wonder how they get 500 active participants in a browser-based app.
Most current approaches use a limited but more economical approach called SFU, or Selective Forwarding Units, which leaves the work of mixing and decoding all those video and audio streams of every participant to each user's device.
Browser-based apps built on SFU struggle to support more than 20 interactive participants.
So SignalWire mixes all the video and audio feeds on the server and distributes a single unified stream back to every participant.
So you can build things like live streaming fitness studios where instructors demonstrate every move from multiple angles,
or even live shopping apps that highlight the charisma of the presenter and the charisma of the products they're pitching at the same time.
SignalWire comes from the team behind FreeSwitch, the open-source telecom infrastructure toolkit used by Amazon, Zoom, and tens of thousands of more to build mass-scale telecom products.
So sign up for your free account at talkpython.fm/signalwire, and be sure to mention Talk Python to me to receive an extra 5,000 video minutes.
That's talkpython.fm/signalwire, and mention Talk Python to me for all those credits.
What do you guys got to add to this restructured text markdown duality here?
I think it's an interesting duality.
And I missed my...
I don't know how to say this.
I find this...
When I first discovered this, I was really fascinated because I was like, hey, this looks cool.
This looks like a really good...
I found it especially amusing to see how mist...
Let's pick one phrasing.
Yeah.
I guess.
I really liked how mist ends up reconciling the complexity or power, depending on how you look at it.
Yeah.
Sphinx, and sort of fitting that into markdown and not...
And having it still look like it belongs there, right?
Because there's a whole bunch of, well, directives, roles, or whatever you want to call them,
that, well, you can use to manipulate the text and include things and have those extensible points.
Right.
Because markdown is not nearly sophisticated enough to handle things like interest Sphinx and
these other types of constructs that's in Sphinx, right?
Yes.
So, like, one example of this would be the ability to have the cards that you're showing
on the screen at the moment, right?
Like, the closest thing you could do for that in markdown would probably be embed a bunch
of HTML.
Yeah.
That or tables when you get basically no styling there.
Like, it's not cards.
It's all jammed together in a table.
But yeah.
And even when you have the ability to have inline sort of markup of markup that's in the
same line as the paragraph that you're writing in, you have a very limited set of those, right?
Like bold italics, underlines, maybe strikes if the platform you're using supports it and
stuff like that.
But with MIS or restructured text or whatever, you have a lot more capability there.
Yeah.
You in part to Sphinx, you in part to DockerDills, which is what implements the restructured text.
On this particular point of the power expressing itself into markdown, I've enjoyed watching Chris
and Chris over the years iterate through this.
Roll some things out.
Realize, wait, you know, it's better in tooling if we do a triple colon instead of a triple
back tick because the body of the directive can then be rendered by some inline viewer or
something.
So I'd be interested in hearing Chris and Chris talk a little bit about your like voyage of
discovery for, you know, what's the gestalt of markdown?
Yeah, it's interesting.
So obviously with, well, with, with Jupyter's book and things we're very much focused on
it, you know, in, in these, in Jupyter's notebooks, you have the markdown set, everything, Chris
and markdown.
And that historically has a single kind of renderer that renders things.
So trying to harness the simplicity of markdown, they're trying to make it look nice as you're
writing with that.
It doesn't look like a complete mess within these markdown cells.
Whilst still having the capabilities of like a restructured text has been an interesting
challenge.
So obviously we had this, we wanted to make the mark, the missed format kind of degradable
to common mark so that it can be passed normally as with a normal markdown parser, although it
wouldn't know what to do with things like notes and all of the other, these other directives
and roles that you, that you can have within the Sphinx.
But at the same time, yeah, have all the capabilities.
So, it's a hard balancing act, I'd say.
I'm trying to just say, here's all of these roles and directives.
You don't want to spoil the simplicity of markdown though, right?
Yeah, exactly.
It's having the readability of source text, essentially, weighing that against the flexibility of actually
making these lovely HTML pages.
Right, exactly.
Chris H., you want to add something to that?
Yeah, I mean, I think that the interesting thing about markdown and probably something that we should clarify for some of the people here is that there is no one markdown.
Yes.
That surprised me, actually.
I didn't realize that.
Yeah.
I mean, there's like, you know markdown when you see it, but there is no like canonical markdown.
The closest thing to a standard that exists is common markdown, which is like an attempt at standardization across a few different communities.
But over the years, what we've seen, whether it's, you know, Stack Overflow or GitHub or whatever, basically, people want to extend common mark in a couple of ways.
So they added a new couple of syntax features to support and they have then created a new flavor of markdown.
So people often talk about markdown in terms of flavors, like what functionality do you want to turn on?
What functionality do you want to turn off?
And there are a couple of nice like renderers and parsers.
And for example, the JavaScript world that will let you, you know, enable extensions in markdown to turn on and off different kinds of syntax.
And so what's interesting about mist is that it's kind of intentionally trying to create like a privileged extension point, either for block level writing or for inline writing.
In part with the goal that you don't have to create a new flavor of markdown if you want to extend markdown's functionality in a new direction.
And I think it's going to create an interesting question of, okay, you've created a new extension point,
but you want to have some kind of reliability or knowledge that your document is going to behave the same in one implementation of a mist renderer or a mist parser versus another implementation.
So there's an extra sort of interesting standards question of, okay, if a directive is infinitely extensible, right?
It's basically like a Python function, but in markdown.
Is there some like minimal subset of directives that you want to support as a part of core mist so that if it's a mist parser for Sphinx or a mist parser for, you know, an HTML website or for some other documentation engine, you know that they'll behave similarly.
That is a big challenge.
A quick question from the audience.
Ryan asked, does GitHub use their own version or do they use common mark?
They use GitHub flavored markdown.
GF.
Which is a superset of common mark?
Yes.
It is indeed.
Yes.
It's got, it now has, I mean, I think if you Google it, I guess, GitHub flavored markdown, it has its own specification, which is built on top of the common mark specification.
The title is different as well.
Yeah.
And it adds a few extensions, a few slightly different things like tables.
Right.
Exactly.
Funnily enough, it's not in common mark, which is quite a basic thing, but that is not in common mark.
That's only GitHub flavored mark.
Yeah.
Interesting.
It was avoiding the politics of what it got to get it to where it got.
There was a decent amount of, oh, this has to be maximally compliant.
Like this has to be the thing that works everywhere.
Yeah.
The minimum functionality, the maximum reach sort of story, right?
Yeah.
And they sort of went, okay, what words basically everywhere?
And that's sort of what ended up becoming some mark.
So any effort to like, oh, how about we extend this has sort of not gone very well so far.
Sure.
So I do want to give a quick shout out to this app I came across recently called TypeHora for writing markdown.
And one of the things I think is interesting, the reason I bring it up is it has the standard markdown stuff, but it also has like inline bits for like mathematics and other stuff like diagrams and whatnot.
And this is the kind of stuff you're talking about, Chris, right, where you want to take the core, but there's ways to extend it in Myst, right?
Yeah.
I mean, that's the beauty of Python, right?
Or a lot of languages where you can define functions is that you can show a lot more creativity and add extra functionality in a very intentional, structured way, right?
So that it's easier for you to replicate other people's work and build on top of it and things like that.
And so in some ways, that's how I think about directives and roles is it's like bringing functions, but into a realm where you're dealing with like human written text or code that is like interpreted.
But inside of, you know, these little directives and things like that, which just opens up a lot of extra room for creativity and trying out different kinds of things.
I guess because we're going to mention this a bunch in sort of Sphinx glossary or terminology, directives are essentially a block of text that you're all saying.
It also has this characteristic associated with it.
Like, hey, present within like a notebook or whatever, whereas a role would probably be something in line.
Hey, make this bold.
Hey, this is actually a link to another thing and stuff like that.
In case folks who are listening aren't familiar, this would probably be helpful.
Although I wish we had said this sooner.
And if you're coming from the front end world, I'm a kind of a refugee from Gatsby in which Markdown is almost like a database format, a lot of structure.
But when it comes to Markdown and extension points and things like that, oh my God, the monkey business they jump through to try and get information from the document to the extension point or whatever.
And they all have to invent their own little mechanism for packing stuff into the space after the code fence invocation.
It's just clearly obvious that they need something like what Myst has done, which is a consistent syntax that just hands things over to restructured text directives.
I think what's interesting about, you know, Spanx and DocuTools is that intermediate document model that exists, which I think is something that differentiates it from a lot of other like Markdown parsers and renders that are out there.
I think a lot of the like a lot of static website generators, they're effectively going from blobs of Markdown mapped onto blobs of HTML as a sort of like heuristic, like it's a very programmatic output kind of a thing.
And actually the original version of Jupyterbook, maybe like two and a half years old now, it was a wrapper around Jekyll, the Jekyll website generator.
But because Jekyll was fundamentally just doing, you know, blobs of Markdown to blobs of HTML, there wasn't that intermediate rich document representation where you can do things like resolve cross-references and collect, you know, bibliographic entries and collect, you know, equation and figure labels so that you can refer to them elsewhere.
And once you add that extra model in, it gives you a lot of extra, I think that's where a lot of that extra like power and complexity comes from in the Sphinx ecosystem.
And so in some ways Markdown, Miss Markdown is just like a, it's almost like a front end on a user side.
It's just giving you, at least in my opinion, a more user-friendly entry point into the Sphinx ecosystem.
Now, most times you just want to write straight Markdown, but every now and then you need something like one of these references over to another part of the site or you need more control.
And so Miss has this ability to say, kind of like run some inline restructured text here, right?
That as well as the ability to just hook into the thing that restructured text would, right?
So that will be the directive.
So you can embed restructured text inline, but that's usually not what you need to do or want to do.
Usually you're just able to directly use the thing that you wanted to use.
So yeah, there you go.
Okay.
So you would go and hook in and write some Python code to process one of these directives.
That's pretty excellent.
Yeah.
And a bunch of these directives exist already in, well, Sphinx essentially.
And you can just reuse them as you would in restructured text in Mist, except with a slightly different syntax because you're operating in a different model of language, you know?
Sure.
Yeah, exactly.
So the terminology they use is interpreted text.
So it's just a block of text and here's the name of the class function that is going to interpret this.
And here's maybe some options to help you interpret it.
And then you can do what you want to do.
Nice.
So does Mist come with a bunch of these extensions already that you can use for maybe scientific graphs or things like that that you can pull in?
Or where do I find more of these if I don't want to write them myself?
So one of the goals of the Jupyter book project is trying to bring in functionality from the Jupyter ecosystem around interactive computational document models like IPyND, Jupyter notebook files.
And also kernels that can run arbitrary, you know, usually data centric code for visualizations and analysis and things like that, where those code will generate outputs like, you know, PNG images or HTML, you know, interactive visualizations or, you know, tables with statistical analyses in them and that sort of stuff.
And so one of the goals of the executable books is also to build sort of entry points for the Jupyter ecosystem into Sphinx and into Mist Markdown.
So you can kind of get the complexity of the PyData ecosystem or the Jupyter ecosystem, but with the ability to embed that into, you know, a documentation narrative structure as well.
So I think that that's where a lot of the scientific use cases come from is like using scientific code that gets executed alongside of your documentation build in a programmatic fashion.
And where those outputs of the code are then inserted into your document in a way that from a reader's perspective, looks like it's just part of the, you know, narrative flow of everything else that was there.
This portion of Talk By The Nome is brought to you by Tonic.ai.
Creating quality test data for developers is a complex, never-ending chore that eats in the valuable engineering resources.
Random data doesn't do it.
And production data is not safe or legal for developers to use.
What if you could mimic your entire production database to create a realistic data set with zero sensitive data?
Tonic.ai does exactly that.
With Tonic, you can generate fake data that looks, acts, and behaves like production data because it's made from production data.
Using their universal data connectors and a flexible API, Tonic integrates seamlessly into your existing pipelines
and allows you to shape and size your data to scale, realism, and degree of privacy that you need.
Their platform offers advanced subsetting, secure de-identification, and ML-driven data synthesis
to create targeted test data for all your pre-production environments.
Your newly mimicked data sets are safe to share with developers, QA, data scientists, and, heck, even distributed teams around the world.
Shorten development cycles, eliminate the need for cumbersome data pipeline work, and mathematically guarantee the privacy of your data with Tonic AI.
Check out their service right now at talkpython.fm/tonic, or just click the link in your podcast player's show notes.
Be sure to use our link, talkpython.fm/tonic, so they know you heard about them from us.
Maybe tell people a bit about the Jupyterbook project itself.
It's an open source project for building beautiful publication quality books and documentation.
As you said, from sort of taking the code in the notebook and generating the output, like some of the graphs and whatnot, in a live way.
But it sounds fascinating.
Maybe when would I use it?
Tell people a bit about that.
Yeah, I mean, I think of the simplest, I mean, from a technical standpoint, since we're kind of riffing off of Sphinx, Jupyterbook is a distribution of Sphinx.
It's basically a collection of pre-configured Sphinx extensions, some of which are developed by the executable books team and community, others of which have been developed by the broader Sphinx community and that are just reused and contributed upstream to by people in executive books.
And those extensions have been created by the other way.
So things like Sphinx Contrib Bib Tech is a bibliography and citation extension in Sphinx.
And that's activated automatically with Jupyterbook.
Right on.
Because of course you're going to need that.
And you want something like Evernote that's going to pull from some source that's always like I always quote this article or something, right?
Yeah.
I mean, just it's a use case that's not built into core Sphinx, like having references and citations and bibliographies.
And so it pulls that workflow into Sphinx via an extension.
So Jupyterbook is kind of a collection of these extensions and then wrapped in a command line interface and a configuration structure that's a little bit more user-friendly.
I think that's one of the things about Sphinx is that at least historically it has tended to be both developed by and catered to the developer community, which is a little bit different from the scientific community.
A lot of scientists know just enough code to be dangerous with, myself included, and are often not as familiar with traditional software development workflows.
And so things like, you know, Jupyterbook is configurable with a YAML file rather than with, in Sphinx, the default configuration is with a Confident.
Oh, interesting.
It's like a Python file directly.
So a little quality of life improvements to make it a little bit easier for people to get started with this more opinionated distribution of Sphinx.
Yeah, it sounds like a fan.
Is what Jupyterbook is called out.
Oh, yeah.
What a fascinating resource for people.
And I meant EndNote, not Evernote.
Sorry.
That's the one you use for references.
There's some good questions in the audience I want to ask you all.
But before we do, I want to ask about MIS just a little bit more.
So MIS looks really interesting and it looks like it allows me to do much more, many more powerful things with Markdown than just straight Markdown.
Right now for when I'm in my code, like say on the website, it might have to take some Markdown content and turn it into a page or something.
I'm just using something like Markdown 2 or one of the arbitrary just Markdown parsers.
Does this make sense as something to run live in your application rather than a publication generation story?
Like would it make sense to replace just using that one function from that library and then allow me to write like directives that do more for the site, for example?
Not exactly sure what you're asking.
I think what Michael wants is the layer under MIS.
There is a parser inspired by, I guess, the JavaScript parser written by Chris and Chris.
It was actually the way I found MIS when I was looking at MIS tune and Mistletoe.
And so, yes, there's a wonderful parser that lets you hand it strings and you get back Markdown.
Yeah.
You hand it Markdown and you get HTML, you mean?
Sorry.
Yeah.
You hand it strings and Markdown and you get HTML.
Sorry.
Yes.
Yeah.
That's what I want.
Yeah.
Exactly.
What I want is a nice way to have richer Markdown, like in an application, in production, not just as, you know, something that I run, like a build process, I guess.
So there's a bunch of, I guess, parsers from MIS.
There's an implementation in Python.
There's an implementation in JavaScript.
If.
Yep.
Work in progress.
So I take that as a yes.
There's multiple implementations of that and you can integrate that into an application if you wanted to.
So I think this is where we're working on this kind of MIS specification of what would be core MIS as in what can we parse, not just in Sphinx, but with other kinds of parsers.
And then you say embedded into applications.
So one of the things we've been working on say is this JavaScript application.
And one of the nice things, firstly, about how we parse, how we use MIS with Sphinx in the Python world is that it uses Markdown at Py, which is a Python implementation of Markdown it, which is a JavaScript.
That is a JavaScript package passing Markdown.
So we use on both sides in Python and in JavaScript, we can use exactly the same, essentially exactly the same code, passing exactly the same.
So then we're working on this Markdown at Dr.
Teels in JavaScript to see if we can bring.
There's much of the functionality, probably not all the functionality of Sphinx in also the JavaScript world, where obviously that's what you need if you want to be able to do anything kind of live without a backend.
Right.
Runtime.
Yeah.
Okay.
Exciting to hear you all are working on it.
All right.
Let's bring this maybe back to the documentation side.
Right now, the audience asks, could we describe the whole process that a MIS document goes through before it becomes an HTML document?
Like what happens to my inputs to get either the HTML or the EPUB or whatever I get?
Essentially, so you have your Markdown text file.
Markdown, we then parse it, as I just mentioned, with Markdown at Py, which turns it into a bunch of syntax tokens.
And then we take them tokens and we convert them into the Docutils-ask syntax tree, which is what Sphinx works with.
And then as we're converting that into the Docutils-ask, Sphinx works with, we're running all of these directives and these roles, this interpreted text against all of the functions, the extensions that have been loaded within Sphinx.
And we end up with this nice syntax tree, Python thing, nodes, and then we say to Sphinx, there you go.
Take it away.
Right.
Traditionally, Sphinx has gone through some sort of restructured text process to generate that.
And you're like, we're going to generate that and give it to you in a different way.
Now just do what you do to generate your documentation, right?
Exactly.
So once you've passed it through this MISTS, or you've done restructured text, you end up with exactly the same thing.
This syntax tree with nodes.
And then Sphinx can go through that and that's kind of agnostic to any kind of output format.
Yeah.
That's just, here's a paragraph and then within that, here's some text and here's a bit of bold and a bit of italical.
And looping this back around to what we mentioned at the start of like the power of Sphinx, right?
Of the extensibility of it is that the markup format that you're writing with is decoupled from anything else that you do with it.
Not the extensions, not the directives that you use, none of that.
They're all sort of a separate step from that.
And that getting that separation happens through the intermediate documentary or doc tree, which if anyone's worked with Sphinx has probably seen mentions of in the build directory and stuff.
So yeah, doc tree sort of acts as that separator.
Oh, fantastic.
And you go from your input text to your doc tree, then to your output for formats, HTML, latex, et cetera.
And on the way, you mess around with all the doc tree to make sure you've got a piece of room to document references and all this kind of thing.
Well known fact, if you go to SourceForge and look at DocUtils, you'll see that they, from the very beginning, have anticipated restructured text not being the only format.
Restructured text is just one.
It happens to be the default parser, but it wasn't intended to be the only parser.
Yeah.
Wow.
A lot of what we've been discussing is things that Sphinx does.
Sphinx, for thought of the most part, is really a good rapport around a lot of what DocUtils provides.
It's much more friendly package, in my opinion, to interact with.
And generally, in some senses, Jupyter Book sort of wraps Sphinx into a nicer package to use.
Sphinx does that for DocuTils, right?
And it builds upon it to give you additional functionality.
It gives you additional points to hook into in the build process that you would still have with DocuTils.
It's clearly not doing anything in addition to, like, in the build process, in addition to what DocuTils would.
It just gives you a better framework to do that.
And a lot of what we've been talking about, apply that intermediate format and stuff.
Those are all concepts coming up from DocuTils into Sphinx.
Yeah, very interesting.
Alvaro out there asks, can we use the AST to translate between markup languages?
Something like Pandoc, which is a pretty neat thing.
It sounds like that might already work.
You've got the different output formats and stuff already, right?
Yeah, so an interesting example of this actually is there's a little helper tool that Chris wrote as a part of the Executable Books project called RST to Mist.
And essentially, it's a converter if you have a bunch of documentation written in restructured text,
and you want to automatically convert it into Mist Markdown.
Because Mist Markdown and restructured text have the same, like, fundamental vocabulary,
they just have different syntaxes that map onto that, you know, DocuTils doc tree,
you can go from one to the other relatively easily.
And that's what the RST to Mist package does, is it, you know, it parses RST into these abstract tokens,
and then it can render those tokens as Mist Markdown rather than restructured text.
And that's because of that sort of intermediate document format that's there.
That's very fascinating.
It's like this huge library of rules, basically, of how do you go from these abstract tokens into like a million different output formats.
And that sort of speaks to the community of the Pandoc world that's been around for quite a long time and is doing a lot of really awesome work there, too.
Yeah, indeed.
All right, let's bring it back to Sphinx a little bit.
I know you all wanted to give a quick shout out to Juan about some of the tutorials that he created, right?
Absolutely.
So one of the things that Sphinx, as we've been talking about, has, it has a documentation site, right?
And it is a documentation generator, but it didn't have a tutorial to get you started.
So that's one of the things that Juan worked on recently.
And I think a bunch of that work is actually piggybacking off of Read the Docs getting funding from EZI,
Trans-Igobab Initiative, as an essential open source software.
I think it's under the E-RSS program, but I could be wrong on that.
And yeah, he worked on a tutorial for Sphinx that, well, introduces people to Sphinx, essentially,
and, well, tells you what your first steps to document your project using Sphinx would be.
Yeah, very cool.
It sounds certainly useful to have, right?
Like the API documentation is not enough to make it feel really great.
All right, so the next thing I want to talk a bit about with Sphinx is sort of the look and feel side of things, right?
Can I really quickly make a plug, actually?
Yeah, yeah, absolutely. Go for it.
I think that one of the other reasons that, like Juan, for example,
has been contributing some of the improvements to the Sphinx documentation is that, like, Sphinx is pretty old.
In the computer science world and technology world, it's like an ancient technology, you know?
It's like eight years old or something like that.
And I think that one of the...
More than that.
One of the...
Dokudones.
Yeah, that's true. That's like the early, early days of Python.
So anyway, my point is that I think that the documentation about Sphinx has been around for a long time.
But I think that the community's understanding of, like, what makes for good documentation has evolved quite a lot in the last, like, 15 years.
There's just more expectations around different kinds of documentation that you expect to find embedded in one place.
I put a link in the YouTube comments for a really interesting framework that's been gaining some traction lately called the Dietaxis framework.
But this idea that you sort of clearly separate out, like, tutorials and how-to examples and reference documentation and explanations.
That's just one example.
But I think that, like, there's...
The community has sort of evolved and made more complex its own idea of what makes for good documentation.
In some ways, faster than a lot of these Python packages that have been around for, like, decades, in some cases, have kept up with that pace.
And so I think there's a lot of low-hanging fruit to improve a lot of these aspects by making contributions to Sphinx stocks and other pieces in the ecosystem.
Yeah, absolutely.
If I can make an addition to your addition.
Do.
One of the things I think of Sphinx as is I think of it as a miracle.
It's an underappreciated miracle.
They crank out bug fix updates with long lists of features and bugs fixed and all over and over for year after year.
They don't get to go do Greenfield development.
They're still stuck in Python 2.3 land or something like that.
They've got this main template, which was written back when Mark Andreessen was still in grad school.
It's just heroic what they do.
Yeah, it's amazing when software continues to live like that, right?
It's foundational software through the ecosystem.
And yeah, there's very little Greenfield development there.
And there's very little sort of exciting work that sort of, it's all complicated problems with lots of complexity to deal.
Both terms of compatibility as well.
Oh, not having enough visibility into how your users are using things to know for sure if a change will break them.
So basically everything is a breaking change.
Let's operate with that.
And the constraint that brings with it.
So yeah.
That's a big constraint for sure.
Cool.
All right.
So let's talk about look and feel.
So there's the whole idea of Sphinx themes, right?
Yeah.
How, and maintained by some people we know here?
Yes, that is.
Yes.
That is.
That is what I use in the image.
Rajan, you want to give a quick shout out to the themes and tell us a bit about it?
Sure.
So one of the things that Sphinx has, as we've mentioned multiple times, is a bunch of variety of outputs, right?
And even within those, even within the HTML output format, you have the ability to change how your output stylized, right?
What theme you end up using.
This is roughly analogous to, I guess, Jekyll themes or Hugo themes, in that you give it a bunch of templates, maybe a bit of logic, depending on what you're doing.
And yeah, it rendered.
Sphinx has that.
And what's probably on screen at the moment, as we've talked about this, is SphinxThemes.org, which is one of the sites I helped update to be more pretty and more up-to-date and sort of a more curated set of, well, themes for Sphinx that you can and maybe should be using when you move away from the defaults, essentially.
As Chris mentioned, Sphinx is fairly old.
And when you look at the themes that shift with it, they're better than aesthetic with them.
They don't look like they were built last week by someone who has been doing this since not too long.
So, yeah.
If you ever go to the Wayback Machine and you look at something that is, you know, a popular website from the early days.
Yeah, I think it's as a Polish.
I don't know.
Yeah.
It's an amazing experience to just like pull up Google or Yahoo.
I mean, to look at something like this and say, yeah, that's one of the biggest companies in the world.
Kind of reframe your opinion.
But having these themes, I think, is an important aspect.
I do think having them look really good is something that, you know, is these are starting to come along, right?
Like I think the furrow theme and the book theme look really nice.
There's the PyData theme.
If you've done Read the Docs, right?
Read the Docs is one of the themes that people I'm sure are familiar with.
I think for a very long time, the only major good theme or one of the two major good themes was the Read the Docs theme.
The other one, Alabaster, which is not the default.
Alabaster is not the default.
And it's been fairly recent that these new themes have sort of come in and gained major adoption in sort of the timeline of Sphinx, I would say.
And I think that's a good thing because, well, I'm personally motivated to do a lot of this, right?
I have, like, one of the themes you mentioned is one that I wrote from scratch.
And it's been an interesting, fun experience.
And I can see why there's not a lot of these.
It's tricky, huh?
I really would like to give you credit for this.
I think Furo is the tipping point, the exemplar that made people rethink what to expect from Sphinx themes.
If I was to guess the two reasons people are switching to MakeDocs, number one is Markdown.
So, Chris and Chris, thank you for that.
And number two is it just looks a lot better.
Part of the reason Markdown or MKDocs looks really good is because there's one theme that's really good there, MKDocs material.
Yeah, the material, yeah.
Right.
That's all it takes.
And I have not.
And I've spent a decent amount of time looking as part of research for all of this work that I'm doing.
Is there any other major theme there?
And there isn't.
There's just one.
And pretty much most of the ecology there just revolves around that.
That isn't to say bad thing.
Certainly not.
And that isn't to say MKDocs is just that.
It's not.
Right.
But a decent amount of the overlap there is.
Well, the overlap there is huge.
It is what I would go for.
And kudos to Squid Funk, whose name is not coming to my head at the moment for the amount of work he's put into that.
Yeah, absolutely.
You and Chris are working on the new chapter of this idea, right?
Which Chris?
Chris H.
I believe the two of you are kind of thinking about what if we didn't have to live with the old contract?
I think the way you're referring to is some of the infrastructure improvements around developing the Sphinx ecosystem.
Is that what you're...
No, I was thinking of...
I thought there was a theme itself you were working on that kind of threw out the basic theme, which is the predecessor of all themes.
And I thought that you had a repo where there was a new theme you were working on.
There is.
Almost like an abstract theme or something.
Yeah.
So the way Sphinx's theme ecosystem works is there's a basic theme.
And what that basic theme has is like the JavaScript for Sphinx's search and all kinds of like fundamental things for Sphinx.
And a very, very, very bare bones HTML structure, essentially.
There's, I don't think, any CSS even.
Right?
So it's just a very bare bones page to just serve as a basic skeleton for you to build upon.
Right?
And I think through the work that Chris and I have been doing on themes and among...
There's more people.
And sort of the name escapes me at the moment.
And one of the things we found out was, oh, there's like a lot of common work across these themes.
That we put into a layer on top of that.
And those things there.
So that it reduces the amount of duplicated work.
It still gives us the bits of flexibility that we want in the individual themes to make opinionated choices, design choices, and whatnot.
But there's a decent chunk of, oh, we all will do the same thing.
Like breadcrumbs have this HTML structure.
Doing things like that will reduce the amount of duplicated effort and lower the barrier for entry, essentially, in your writing.
Which is sort of what I'm personally motivated in at the moment, having written one.
It's like, oh, this thing goes to my right sort of brain areas.
Because I, as I've mentioned, I'm a maintainer on PIB.
Developer workflows are a thing that I happen to be interested in.
And I would say have a decent amount of experience dealing with.
So I was like, hey, this looks like a great place to put in a bunch of my JavaScript, HTML, web tech experience, combined with a bunch of Python packaging and user workflows around that.
And sort of put in energy there.
So that led Sphinx team builder, which is like...
Fantastic.
Yeah.
Yeah, it's been excellent.
I think it's kind of just bringing in that maybe what Sphinx has lacked in the past is that kind of expertise in web design, really.
I mean, there's a lot of, you know, excellent people working, as you say, within Sphinx and DocuTools and things on the kind of back end and how all that works and all the Python code.
Possibly there's been less so in the past of going, right, let's actually make all this good work and actually show it off and have these just lovely themes that actually show what you can do.
It was super fascinating for me because sort of when I jumped in, I was like, oh, recreationally, right?
And to be honest, my motivation jumping into the Sphinx ecosystem was precisely this of like, I want it to look better.
Like, it doesn't look good.
I would like it to look better.
And funnily enough, none of this would have happened if pip hadn't gotten a grant where we had a bunch of computer experience experts sit with us and our users and sort of have that channel of feedback through them as well as their expertise.
And just having them state multiple times like, hey, PIP's documentation is not that great to sort of navigate and stuff.
Like, there's content.
They don't know how to get there.
And sort of in those conversations, I was like, yeah, I don't like this site.
Now that you've made me look at it a bunch of times.
Let me put something on the screen for you all just to put side by side here.
And just think about this.
And you all can pull this up really easily who are listening.
Just think about this from the perspective of someone who's choosing a programming language or new to programming and deciding, is Python the space for me?
You know, if on one hand, we've got, you know, just the docs.python.org and the other, you know, something like Tailwind, where you look at it and it's just like, it just feels, you know, so fresh and welcoming.
Whereas the other, this is not to take away from the hard and important work of writing the documentation, but the way it feels when you land there, I think, is in desperate need of the work that you do.
Yeah, but Michael, have you seen what it looks like in a man page?
I know.
It probably is looking the same, right?
Those three man pager users are really happy.
Pretty close.
And that isn't to say those users aren't about to be clear, right?
Yeah.
I mean, it's kind of like moving from MySpace to Instagram.
It is.
And like I said, I'm not bashing on it.
I'm just saying this is the face that that part of Python is presenting to the world to say, we want you here.
Come be with us.
Right.
And there's a different face that other places are putting on that I think probably will appeal a lot more to people who don't know better.
You know, they're getting to write in JavaScript.
And this is really an aspect that I would sort of think, I would like to put my energy into this and make these improvements.
And I'm by far not the only one.
There's, in fact, now a documentation working group being formed in the CPython core development community.
The folks who develop the language around improving this.
And there's like a public issue driver that hopefully going to sort of start ramping up soon because I would like to be involved with that.
And I'm aware that Paul is as well.
And yeah, this is by no means news to the folks involved.
They're aware of this.
And I think the first issue itself in this sort of dogs community issue tracker that they have is moving to a more modern documentation theme.
As it turns out, there aren't many in Sphinx.
So that's sort of been another thing I've picked up and gone.
Yeah.
So maybe one more shout out to the Sphinx theme builder that you put together, right?
Yeah.
Sphinx theme builder comes in nicely into this.
So there's a bunch of Sphinx themes today, right?
There's Furo.
There's Sphinx book theme.
There's PyData Sphinx theme.
There's Alabaster.
There's a bazillion of those.
The first three that I mentioned, right, are the folks on this discussion are involved with those.
And one of the things that came out of having worked on all of these was it would be nicer to simplify these workflows a bit, make the interaction with JavaScript easier, reduce the amount of bootstrapping required and stuff like that.
And that essentially ended up in Sphinx theme builder where it sort of streamlines the JavaScript and Python build processes and sort of makes the development workflow easier.
Yeah.
It even comes with a development server that does like refresh the browser on change, right?
Yes.
And I think that's also really nice to have in Sphinx documentation authoring as well.
And Paul sort of mentioned this earlier of like me taking up maintainership of too many things.
So I went, I like this.
And the repository had maintainers needed on it.
So I just went and opened an issue and said, hi, add me.
And I'm more basically a defactor maintainer on like live reload as well as Sphinx auto build, which is nice.
If you don't use Sphinx auto build and write a lot of Sphinx docs, start using it because it's great, I think.
Yeah.
Awesome.
I love those auto reload aspects.
Yeah.
All right, you guys, we are just about out of time.
Maybe I'll open it up for if anyone else wants to just give a shout out to something or mention something while we're all here together.
What have we not covered that we need to quickly talk about?
The main thing that I would just say is to reiterate that I think that what a lot of these like the theme conversations and improving developer workflows around the Sphinx ecosystem, one of the reasons that they're so successful is because I think that there's a lot of low-hanging fruit in the Sphinx ecosystem to basically like signal boost all of this work that's been done over the last, you know, 14 years.
And DocuTales and Sphinx and building this documentation engine and this whole community of people writing extensions for it.
In a lot of ways, I think that there's a lot of potential energy there that hasn't been unlocked yet, in part because of some of the things around developer friction or themes that don't look kind of like modern and nice and web develop-y.
And I think that there's still a lot more low-hanging fruit that can be accomplished with, for example, improving documentation about Sphinx itself or the extensions or whatever.
And so I think that all of the success of these projects is largely possible only because they're kind of piggybacking on top of this really well-established community where a lot of work has already been done.
And a lot of kudos go out to that broader community.
For sure.
And one other thing that I'm sort of hoping to see coming out of this is as sort of these efforts around making it easier to present your thing nicer, making it easier to write your docs and all of these happen.
So, you know, because when you have something that looks nicer, that's all of that, it also results in a better quality of documentation where because you're able to go, oh, actually, I can see the structure of my site more clearly.
I think I would like to restructure it slightly to make it clearer what the flow is.
And, oh, I'm missing this bit of content in this section, but I have it there.
Maybe I should just edit it.
And when these things become more obvious to you through either clearer markup or clearer site design or whatever, it will lead to better documentation.
And also a lot more people would be willing to write those.
Because it's more like, oh, why am I writing this?
Yeah.
And also moving away from Sphinx just being seen as a developer documentation into Ghibli books, trying to do, make it available for scientists and things to go, oh, wait a minute.
I can use this relatively easily and I can share my work or I can write tutorials, science, share my research and things like stuff like that.
That part's really interesting to me.
And it's why I did the course with Michael on static websites, not static documentation, is to think bigger than just docs.
I have an interest in knowledge bases.
I'm a developer advocate.
We create artifacts that are rich and interconnected and richly linked.
Sound like something?
Sphinx has inside of it this engine.
Sphinx and DocuTools has this engine inside, which nothing else has.
The very first contact you have with the mist in the course that I did is just the humble link.
But when you do it in mist, it will tell you if the thing on the other side isn't there.
It'll extract the title and inline it on your side.
That is magic to all these other systems.
And it's knowledge-based kinds of things that are valuable.
And I think that we could tell the story of Sphinx in a bigger way beyond documentation and start doing all of the things that people on technical teams want to do for storytelling.
I feel like I want to interject and mention that, hey, you know Sphinx can do blogs?
Yes, there's the Ablog extension.
Right on.
And Chris H, at least, has his blog on his personal website, as far as I'm aware.
Look inside the code of Ablog, which I've followed for years, it shows you tapping into the equivalent of front matter and walking through all the doc trees and looking for structure and doing back references.
People don't expect to be able to do that in Markdown.
It's a document database.
That's what you should think of, Sphinx says.
And I think there's a lot there of unlocking.
I really do want to reiterate what Chris said of there's a huge body of excellent work that has been done over more than a decade.
I mentioned older than me, it's like four years younger or something like that.
I'm four years older than me.
Okay, whatever.
I was wrong there.
But yeah, there's a huge body of work there.
And there's just, it sort of needs the little touch of, hey, paint.
Get it to look like it belongs in the sort of modern web.
But it also needed Mist.
It needed Mist to come along and express that power in a human-oriented way.
And there are so many things in Mist that are mind-blowing.
People haven't scratched the surface with Mist yet.
I actually, to that point, one other quick plug that I would give is, I know we've been talking about Sphinx in this conversation.
But to reiterate, I think that the goal of Mist is to be a tool or implementation agnostic specification for Markdown.
And I think that there is a lot of exciting possibilities if we can sort of find the right standards to apply at the Mist, you know, directives level or roles level or whatever.
And to see if you could get a flavor of Markdown that is flexible enough that it can be reused across like a few different kinds of applications.
Maybe some are pure web page, maybe some that are full-blown documentation, maybe Pandoc, you know, whatever.
And so I invite people who, if they can think of use cases or tools that they're working on or ecosystems that they're working in,
that would benefit from something like a sort of tool agnostic flavor of Markdown that has natural block and inline level extension points,
then reach out and we would love to chat because I think it would be really cool to see Mist being applied in other kinds of contexts as well.
Yeah, it would just help it grow, get stronger.
Yeah, I guess on a similar sort of call to action sense, I think if there's anyone around in listening who has sort of JavaScript and web design jobs
and sort of finds all of this interesting and wants to sort of contribute to making Sphinx look prettier, like reach out to honestly any of us on this call.
And yeah, we'd really like to have more people on board, not least because it's good to have fun collaborators to collaborate with, as Chris and Chris have been,
but also because I think the ecosystem could use a bunch.
I think Sphinx itself and even Dark Itals, like the maintainership story on those and the work that those maintainers do is,
well, the maintainership story is, let's leave it at interesting.
And the work that the maintainers do is really amazing for the amount of resources that they have.
Yeah, fantastic.
Good call to action.
Let's leave it there.
Let me ask you all one of the two final questions I typically ask before we get out of here.
Regine, I'll start with you.
If you're going to write some Python code, what editor are you using these days?
I am using Visual Studio Code.
Okay.
Used to use Sublime Text, but I've sort of switched over.
Yeah, I feel like that's the natural transition for Sublime users that seems to be able to advertise.
Good it is.
I'm wondering which one you might be using.
No, I love PyCharm as well.
The best, baby.
The best.
Absolutely.
Right on.
Chris Siwa?
Mainly Visual Studio Code.
Is there, I suspect, probably some notebooks in there as well.
There's probably some notebooks in there as well.
Like some Jupyter.
Partly Jupyter Lab, but mainly Visual Studio Code.
And there's also this extension for Visual Studio Code.
And we're working on the extension for Jupyter Lab as well.
Oh, fantastic.
All right, cool.
Chris?
H?
I kind of split 50-50 VS Code and Jupyter Lab.
Basically, if I'm doing development, software development, then I do VS Code.
And if I do data exploration, interactive computing, that kind of workflow, then I use Jupyter Lab.
Over on the notebooks.
Right on.
All right.
Well, thank you all for being here.
It's been really fun.
And thank you for all the hard work on bringing all this stuff up to 2020.
Plus.
Wait, wait.
You have two questions.
You only ask one.
I know.
All right.
Really quick then.
Notable PyPI package.
And so I don't want to take too much of your time.
Okay.
I guess for me, it'll be Pursuit PyPair, PPB.
It's a really cool educational game engine that's way better than what I had when I got started
with gaming.
Yeah.
I just finished doing the Python Bytes podcast with Brian before we started this one.
And ESA, the European Space Agency, just put two Raspberry Pis on the International Space Station
for kids and students to program against.
I'm like, that's way better than the turtle I got to drive around when I was in school.
All right.
Paul, really quick.
What's a package or library you want to just give a quick shout out to?
I have a fascination with dependency injection in a human oriented way.
Antidote.
Okay.
Very interesting.
That's new to me.
Chris S.
Got a library you want to give a quick shout out to?
So is that Chris S?
Yes, it was Chris S.
It was.
I'm Pipex.
I hadn't used yet until recently.
And yeah, I love you.
Yeah.
I'm all for that.
People talk about how it's hard to distribute Python applications and little utilities by packaging
them up because, well, you got to download the scripts and then set up the environment.
That is the homebrew of the Python world.
If you want something, I can go to the terminal and just type a command and it runs.
Well, if you Pipex install it, it's going to just be there and it's fantastic.
I love it.
People should use it more for that use case.
Chris H.
I feel like in the name of improving UI, UX and window dressing on technology that some
people think is outdated.
I would shout out to Rich.
Oh, yeah.
Sort of like UI components, visualizations, whatever.
I would love to find a way to get Rich into Jupyterbook or even Sphinx or something like that because
I think it makes for a really nice user experience.
The only problem is that the maintainer of Rich is much better at Wordle than I am.
And so he's like consistently beating me by two or three tries.
Every day.
Fantastic.
Let me wrap it up a bit because this seems relevant.
One of the things I've been doing through work as well as personal time is improving error
messages in Fit and Rich has played a decent thing.
Oh, yeah.
Fantastic.
So it's pretty likely that in the coming release or two, you'll see better error messages,
partly thanks to Will's work on Rich.
Yeah, absolutely.
He's got the whole traceback enhancements and everything.
All right.
Thank you all for being here.
It's been great.
Chat with you later.
Thanks, Michael.
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.
Add high-performance, multi-party video calls to any app or website with SignalWire.
Visit talkpython.fm/SignalWire and mention that you came from Talk Python to Me
to get started and grab those free credits.
Tonic.ai creates quality test data that does not contain personally identifiable information.
Your generated data sets are safe to share with developers, UA, and data scientists.
Most importantly, they behave like production because they're made from production data.
Check them out at talkpython.fm/Tonic.
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.
I'll see you next time.