Armin Ronacher

Hello, and welcome to podcast. In it, the podcast about Python and the people who make it great. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show, you can visit our site at pythonpodcast.com.

Linode is sponsoring us this week. Check them out at linode.com/podcastinit

and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project. We are also sponsored by Sentry this week. Stop hoping your users will report bugs. Sentry's real time tracking gives you insight into production deployments and information to reproduce and fix crashes. Check them out at getcentury.com.

You can also visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch. And to help other people find the show, you can leave a review on iTunes or Google Play Music, and tell your friends and coworkers.

You can also join our community at discourse.pythonpodcastdot

com for your opportunity to find out about upcoming shows, suggest questions, propose show ideas, and follow-up with past guests. Your host, as usual, are Tobias Macy Chris Paddy. Today, we're interviewing Armin Ronneker about his contributions to the Python community. So Armin, could you introduce yourself, please?

Hello. My name is Armin Ronaha. I'm doing a lot of Python development for many years at this point. I'm sort of the creator behind a lot of Python libraries, including the Flask framework, the vector WCI library, change the template engine, Lecto CMS, and a bunch of other things. I'm doing sort of independent software development out of Austria now, and I'm spending most of my time contributing to the

Sentry open source project, which also has an sort of attached

software as a service business model, which actually is quite significant at this point. So that's that's pretty much all about me, I guess.

So how did you get introduced to Python?

That's a long time ago.

There was

the so it basically happened

in 2 stages. Stage 1 was I found a book.

It was called Python for Kids. I think it was written by

I guess it might have been an Austrian. I'm not entirely sure.

Georg Linge, I think. Okay, Georg Linge. I bought this book

when I was, I

guess, 13 or something. So it's a really long time ago, and I tried to use Python.

I signed up on German Python Community Forum at the time. And

through that,

I found Ubuntu Linux.

And then I actually stopped doing Python for quite some time, and I started

programming in PHP for

this sort of German Ubuntu community, which I found.

And then

that's kinda how I learned proper programming. And the proper programming, it was mostly just changing PHP BB installation and the cookie and all the kind of stuff that was running there.

And then

when we run to more and more problems with Docker Wiki,

we sort of there as sort of the team that was maintaining the Ubuntu community website

tried,

myMine Wiki.

And and through that, I sort of started doing Python again,

or Python properly again. I only did it as a sort of fun exercise

before that.

And the interesting thing timing wise was that when we wanted to do more web development with Python, there wasn't really anything there. So if you've ever used MimeMine Wiki at that point,

there was I think WCI as a specification came out in 2004, if I remember correctly. So Moin Moin Wiki predates this and used to be this CGI based,

application.

And Whiskey, I think, came out WTI came out, I think, a year before Django. So when we started doing this, there was no Django. There was no anything else.

So we we didn't have a framework to go with.

And that wasn't really a problem for Moin, but I had the the sort of

big plan to rewrite PHPBB

in Python.

And then I ran into so many roadblocks that I just had to do, like, the the plumbing, basically. And that's sort of how

all of this started, I guess.

And what was the first open source project that you created in Python?

So the the original goal was to have

a PHPBB replacement called Puku, and that's sort of where, I guess, all of this Puku shenanigans comes from. And that might have been sort of the first project, but it was always super,

like, early, and it never got a release or anything of that sort.

But the support libraries for it,

did. So there was, I think it was an early library called Kluberts,

and there was another 1 called Chinga. And that is not the Chinga 2 now. That was sort of the the earliest version of it.

That might have been the first open source project

in a way, I guess.

You've been involved in a lot of open source work since then. And I know that some of the projects that you originally created have switched maintainers, and you sort of handed them off. So what is your view of the responsibility for open source project maintainers? And how do you manage smooth handoffs for projects that you no longer wish to be involved in?

Yeah. That is,

I would say a complicated topic because I would say that my situation is I wouldn't call it special, but my situation is a little bit weird because I never intended my stuff to become popular. So it just happened.

And I didn't really have a proper plan for the projects in the beginning.

It was just sort of to scratch my own,

itch, which means that when projects get popular, all of a sudden there comes responsibility with it. And when you never had the plan in the beginning to sort of have a project at certain size and it just happens, you don't notice all the sudden how much of a important fact of the project you are for the health of the project. So the first couple of projects I gave someone else, I did it in a couple of stages. So the fir I think the first project that I sort of handed over to another person was, wasn't actually a Python project. It was a

PHP 1. There was a templating engine I wrote for PHP called Twig, which is sort of,

a clone of Ginger with some modifications,

which I handed over to the Symfony framework people. And that was easy to do because I didn't have a emotional attachment to it, and that was completely hands off. I didn't do anything with it anymore afterwards. The thing

I handed over next, I think, was Logbook. And that was also easier for me because

Logbook was me and Gregor,

Georg, sorry,

who did,

the Sphinx documentation tool and who sort of was my mentor for Python development for a long time. And that was quite easy to hand over as well because both of us lost the interest in this whole concept

entirely. So it was just trivial to hand over. It's a lot harder to do this sort of stuff when you use the software yourself still. Because on the 1 hand, you consider it to be solving your own problems, but you also have to acknowledge that then all of a sudden there are other people's problem which happened to be solved by the same tool. And your own goals and the goal of other people might necessarily align.

I think in many ways, that's sort of how Flask suffered from this a little bit because there hasn't been a release for a long time, and it would have been probably a good idea to involve other people on a much bigger scale early on. But I was very afraid that it would go in a direction which I don't really have in mind. So balancing this is tricky. And I I don't think that I have a good answer for how to do this properly yet, but it's it's something that I want to improve on. I it's it's sort of my goal for this year and next year is to make it possible for community

people to be involved in my projects to a much larger degree than it is currently the case.

You know what's kind of amazing hearing you discuss some of these projects that you've built and then and then given over to other maintainers.

There are lots of people who come up with a number of side projects,

but your projects grow legs. They take on a life of their own and like Twig is an example. I know for you that was 1 of your very early projects, but a couple of jobs ago, we used I I worked for a PHP shop, and we used Twig, the modern version,

extensively for some of the work that we were doing. It's really impressive how persistent

your projects in particular are and how they continue to grow and evolve after your involvement has ceased.

Yeah. I'm surprised that some things became so popular.

Ginger for us especially for me was, I didn't notice how many people used it, for a really long time. I almost forgot about the templating engine in itself because it was as far as I was concerned, it was, like, feature complete. I didn't want to change anything about it. And I sort of unsubscribed from the own issue tracker in a way almost. But it got more and more users, and I didn't expect that.

That was before Flask, I think. So, yeah, it's I don't know why that happens. I I think in in some ways, it's because the projects are sort of the right size that 1 thing I did with the project initially, which I think helped, is I never built them in a way where you can't take it and make your own, I guess. So, if you look at the early Flask documentation, it's still in there. There's a chapter in the documentation which says that what happens if you outgrow Flask itself and how it's structured internally and what you can do with it, which is sort of based on the idea that they could literally copy paste the entire thing and and modify it to your needs. Because I I mentioned earlier that part of why the library started was this idea of build a PHP EBB,

replacement.

And 1 of the things that PHPBB

sort of did as a software is that it was running entirely on top of PHP. So there was no framework involved or anything of that sort. And it was very hard initially in Python to build your own software that doesn't require lots of dependencies. And that was before there was a reasonable package management because now we have pip and virtualenv and and all this sort of stuff. But when my library started, the most common way to install things from the Internet was to download a tarball manually, unpack it, and from setup.py. Like, the idea to have automatic package man management wasn't there originally when when I started my project. So some of the the motivation, I guess, to have this idea that you can take something and modify it is no longer as relevant as it was before, but it still sets sort of a a maximum size that I want for each individual project, which makes it much easier to sort of to get accepted in other people's code bases. So I know that there are lots of people who use modified versions of the WSGI library I wrote, which sort of they forked off. And and that's sort of why it sits in in some people's code bases as almost their own part of the framework at this point. So I think that might contribute to why it sort of gets such a wide usage.

Yeah. And I think

that having a narrow scope for a lot of the projects that you have created has also contributed to their expansion. So for instance, Flask,

I understand

originally started off as a single file framework.

And because of the fact that it has a number of points that you can hook in, particularly in the case of blueprints but also in the case of various plugins, it has allowed people to create this large ecosystem of additional plug ins that lets Flask scale to much larger projects. So there are some installations of Flask that rival even the size of some Django applications. But because it's so adaptable, it makes it much easier to essentially cobble together your own framework from the core of Flask and the various other plugins that are available to it.

Yep. I think the build your own framework approach is, is sort of why it's got such a huge number of users. And I I totally believe in this approach to be honest, because I have never seen an installation of Django, which after some period of time did not start to replace lots and lots of Django internals with with your own things. And I I think it's just natural in how software develops. And because of that, I just like the idea of just taking this as a as a matter of fact and incorporating into the design of libraries.

And another point that I'd like to circle back to is you're mentioning that the original Ginger project you felt was fairly feature complete, so you didn't really do much active development on. And that's 1 thing that can be hard to manage people's perceptions on is if they see that a library hasn't had a significant update within

So Flask, for instance, and also Logbook, they're both very mature, well developed pieces of code that don't require significant changes. And so they can still be used as is. The only modifications

perhaps being minor updates to make them compatible with newer versions of Python as they come along. But in and of themselves, they're very well featured libraries that can still be used. For instance, I've used logbook

in a previous job less than a year ago. And I thought it was 1 of the better logging solutions that I've used. And while it hadn't had significant updates, it still did the job that it was supposed to do and was very easy to extend

and made to suit my purposes.

Yeah. I think that's true for the most part.

We've mentioned a few of the large successful open source libraries and tools that you've made during your career. What are some of the projects that might be less well known that you think people might find interesting?

Less well known of my own open source libraries. I think for the most part, Python libraries,

all are fairly used, I guess.

I wrote a bunch of libraries

which are sort of never went anywhere because I didn't want to in some ways. 1 of them, I think, was so long before Sass and everything else, I wrote a library called clever CSS, which was inundation based CSS,

which I totally didn't like, but that sort of still exists, I guess. You could theoretically use it. I made a port of or another port. I made a a version of Haml, which was a indentation based templating language for Ruby, I think originally. I made a port of that to Python, which converted sort of similar looking templates into a Genshi stream. That didn't get anywhere because Genshi turned out to be conceptually very awesome, but way too slow for the Python interpreter. That was sort of a disappointment. That still exists. A library which many people don't know exists, but is super popular because of dependencies is, mark markup safe, which is, an implementation of strings which have awareness of HTML and XML.

Yeah. I mean, the I wrote a ton of stuff over the years, in in regards to libraries. There's, there are a bunch of Rust libraries at this point, for Redis. Yeah. I don't know. There are lots of them. I I have a list somewhere.

And circling back briefly to Flask, if I understand the history correctly,

the original reason for your creating that was a sort of a pun on the bottle framework. Is that correct?

In a way. So the the name obviously is is related to bottle. But yeah. There there's there's a origin story to to Flask. What I what I find interesting is, like, I had all of those libraries, but there were so many frameworks that were just building more monolithic

code bases where they reimplemented

everything in there. And the reason why I was very unhappy with this sort of development was because when you have been doing web for so many years, and I already did it a couple of years at that point In Python, you you know more and more about the quirks of of the ecosystem and how much work it actually is to support some of those things.

So for instance, the WTI specification, technically still, but in practice, that's no longer as relevant. Has, a very specific way of dealing with input data from web clients that comes through the server. And dealing with this properly to support

fully conforming WCI servers basically meant you have to write your own form parsing library. And most people didn't do that. Most people just used the standard library CGI module with with WCI, which turns out to be against the specification. But people, I guess, didn't care as much because most servers didn't cost that much of an issue for most servers. But there are a lot of those little things, and I felt like a I don't like the idea that this is being reimplemented all the time. I wanted to have almost a standardized implementation of this sort of thing. And there were a couple of frameworks. Boddle was just 1 of them. And Boddle wasn't even all that relevant to the creation of Flask.

There was another framework called web2py,

which I had very, very strong opinions about. And if you actually look I don't know if the website is still there, probably not, but, there was, this denied framework which I made, which was literally, sort of a 1

file framework, which was looking very similar to how Flask ended up looking. But it used to bundle all the dependencies of it in a base 64 encoded string within the file. So that was, like, the framework code on top, and then there was a huge line of, like, 2 megabytes at the end of the file. And when you imported it, it unpacked the dependencies into a temporary folder and then SIP imported it. That's sort of how that started. And I I didn't write my name on it or anything else.

I I just made a fake, like,

screencast of it. Had a friend of mine, make a fake French accent and then talk about how a guy named, Le Havre invented this framework, and I made a bunch of fake quotes on it. And I included a fake quote of myself about the framework, and I wrote some I wrote something like, I have never seen something as dis I I I didn't see it. Never saw something as disgusting, but I I made a statement that would read that way. I don't know what it was. But the interesting thing is that on hackcanuse, on Python, on Reddit Python, I don't know where it was. Some other framework maintainers said that all the only negative quotes on this framework was by me, which I found hilarious because it took, I think, a couple of hours to realize that it was actually a huge choke and and not a real thing.

I love instances like that where you get code as satire and humor and social statement all rolled up into 1.

Yeah. It was fun. I made another 1 way less popular, thing the year afterwards where I wrote the Flask extension which implemented,

what was it? It was called, I think, enterprise support for Flask, and it implemented a functioning soap library, because I actually needed 1 at that point, and I made a hilarious website for it, but I think it's gone as well. Yeah. I don't know. It's like sometimes satire is very close to reality, especially when it comes to sort of enterprise supporting things.

Definitely. And, that's 1 of the great things about the Python community is that it still has maintained its sense of whimsy, particularly given the namesake of the language itself.

Yeah. I think I guess it goes a little bit in the discussion in regards to the future of Python. But I think that it doesn't make any sense at all to pretend that Python is something it's not. You will never succeed by making Python more enterprise because there is so much good stuff already in the Java community for, like, this really large scale deployments that there is just no point in even trying to to be that. So you have to artificially limit yourself to say this is sort of where Python stops making sense.

Yeah. And that humor is really what makes the Python community

as

interesting and welcoming as it is. Because without the humor, then it just takes a lot of the fun out of even working in the language because there are so many different little hidden gems like the, wrote 13 encoding for the import this module, which has no practical purpose. But it's a humorous little thing nonetheless when you do come across

it. There's lots of stuff like this.

Even talking to the guys who are kind of responsible for the PEP proposals, there was more laughter in that episode, and those guys are as core as core can be than we usually see. So, yeah, it's it is interesting how witty humor really pervades the community.

I noticed that you recently worked on the PIPC project. Please tell us about it.

Yeah. So PIPC is a project which is basically a thing that wraps pip to install the binaries. Or binary is the wrong name because it's basically just a shell executable. But it it installs the scripts of Python packages

in self contained virtual MFs and then links them into your load path. What this basically means that if you have, let's say, you have a software like Mercurial,

which provides an HD executable,

you could use pipc to pipc install Mercurial, and it will then install Mercurial into a separate virtualenv and then link the HD executable into your load path. That's sort of the idea behind it.

That's really cool. And that sort of gets you out of system Python dependency hell. Right? Yeah. So that's the idea behind it. To be honest, that's the kind of thing that I wish Pib would do by itself. So for instance,

if you ever used Rust, there's a their package manager is called cargo, and you can cargo install something, and it will, do something similar to that. It will set up a temporary build environment. It will download all the dependencies in there. It will compile it in there, and then it will take the build artifact and move it to the appropriate location. So

my goal for PIPC is that it eventually just dies because it gets replaced by PIP being able to do this itself, especially also because the way PIPC currently does certain things in when you pip install,

a project and there happened to be shell executables in there, you don't necessarily know which executables

come from which library. A good example for this is, for instance,

if you install,

pigments. Pick pigments is a syntax highlighter for Python, and it also has a command line executable called pigmentize.

And

when when you install pigmentize,

you also install the dependency called,

docuTails.

Actually, that's not true. If you install Sphinx let's let's go with Sphinx a bad example. So if you install Sphinx, the documentation tool, it has 2 dependencies. It has pigments, and it has docuTills. Both of those tools, pigments and docuTills come with command line executables, which most people don't know about. So if you install pigments, you get a command line executable called pigmentize. If you install docuTails, you get a bunch of doc command line utils

called rst to blah blah blah, like rst to HTML, rst to XML, that sort of stuff. So when your pipc install sphinx, what you actually want, you only want the sphinx executable. You don't want the executable of the dependencies. So that's sort of what pipc does is it only installs the executable of the most direct library you install, which unfortunately also means that you can't PIPC install some things. So for instance, if your PIPC install,

tox, I think is it tox? No. If your pipc install defpi, this def this local development thing, then it doesn't install anything because defpi pi has 2 dependencies, 1 called defbi client, 1 of them called defpi server, and only those provide the executables.

So in the actual first thing you install, there's not any executor, but also Pip says, oh, I there's no executor window. It will just throw away everything I did. So to for something like pipc to work properly, there would have to be an amendment, I guess, to the Python packaging

metadata,

which says I am actually providing this executable. So for pipc to get better and and also to work on Windows and that sort of stuff, that will have to sooner or later move into PIP itself or just the Python packaging infrastructure.

So following on from the last question, where would you like to see the Python packaging infrastructure go in the future?

It's a loaded question.

That's a super loaded question because,

it's a very complicated topic, and I have very strong opinions about it. Because I think that the core problem that we have with packaging in Python is not actually the packaging even though the packaging in Python is is kinda screwed up and everything. The setup dotpy file really should be a declarative

any file or something of that sort. Like, there's a lot of stuff that is wrong with the distribution of Python packages. But I think the the issue why we're in in the place where the Python packaging just didn't really get anywhere reasonable is because we have a very limited import system. So you're naturally

limited by what you can do with dependencies in Python because each library has a guaranteed import name. So for a a good example is 6. 6 is a library which helps you port things to Python 2 and Python 3. Every second Python library depends on a version of 6 at this point, just because there is just so much code which wants to run on Python 2 and Python 3. So in Python, there can only be 1 6 library. So unless you vendor it and rename the library and put it in a different input path, everything will import 6, and it will look in sys modules

within key 6. That means that all the libraries that you install have to agree on sort of their peer dependencies.

And there is no reasonable way to fix this in Python. I I looked into this issue a couple of times. I wrote

all kinds of import tags to try to, proxy the imports to other places. But there's just so much code in Python that assumes that libraries have a stable reference name,

that you just can't really do

what other languages achieve in the meantime. Like, in Node, for instance, instance,

if you NPM install a library, you can have dependencies in var various different versions, and they can coexist because they don't

have a guaranteed input for location. Likewise, in in Rust,

dependencies can be exist multiple times because there's a there's a system in place which can tell different parts of the system to use different versions of the library.

And to be fair, also, languages like Rust and Go are statically compiled languages. Right? So they have it a lot easier in the sense that they need to resolve dependencies at compile time. And then they need to, you know, obviously make sure that any runtime dependencies are bundled into the executable, but it's kind of a 1 time thing. Whereas language

is, pardon me, Python's

super dynamic nature means that you don't get that luxury and, you know, you need to be able to dynamically

load code at any point in time. I don't think there's a big difference between that because if you look at how Rust deals with some of these problems,

you so first of all, from a complexity point of view, it's the same because it's dependency management. It doesn't disappear just because you have compiled the thing down now. First of all, you could instruct Rust to not statically compile everything together in 1 binary. So then you have, like, a bunch of different libraries which will be loaded at runtime. So you still need to figure out a way to, hash them properly to to give them individual names, make sure that the right code looks for the right library. So I think that conceptually, it doesn't get any easier by compiling it. The the 1 big advantage it's something like Rust has over something like Python,

is that it could learn from a bunch of mistakes from people before.

And also it has so 1 of the problems I think that there's a very prominent in Python is that the so you can solve the Python layer theoretically quite nice with changing the language to a certain degree. But it also gets very tricky when you have, native dependencies like, OpenSSL,

things like that. Because all of a sudden, you have to extend

sort sort of your dependency management into sort of the native parts. And and that's, I think, why Rust has it a little bit easier because they already had to build all the infrastructure for dealing with Rust sort of, compile and separation so they can extend quite, I would say, in quotes trivially to also managing c extensions. That's much harder to do in Python because Python doesn't have a compiler. It doesn't have a linker. It doesn't have any understanding of infrastructure in that place. It only has distutils, which can talk to compilers. It can talk to linkers, but it doesn't have any good support

beyond that. So even if Python manages to improve its sort of Python dependencies, it will not yet have an answer to native dependencies. But because Rust is sort of a native language, it has LLVM as a sort of back end for it. It has an easier time managing binary dependencies as well that are not written in Rust. So I think there it has a huge advantage that Python just doesn't have.

So because I'm largely ignorant of all the subtleties involved, 1 thing that I hear people talk about and talk about maybe choosing something like Go or or less commonly, Rust, is the idea of being able to build a statically

linked executable that you can just drop into your target environment and go. How feasible would something like that be in Python?

First of all, it's very feasible. It's just a question of doing it. 1 thing that like, this is not even a new request. Py2exe

and that sort of stuff exists

for longer again than modern Python packaging infrastructure exists. It was just that there was never really an agreement and that being something that people should do. So where Go and Rust and some other libraries,

sorry, projects have people behind it that see this as an important goal. Python for many years was driven by people that see this as sort of an anti goal.

And I think a lot of sort of I wouldn't call it negative credits, but something to that degree goes to Debian because Debian's maintainers for Python had very strong opinions about how things should be managed there, and that worked reasonably well when Python only had a handful of dependencies.

When Python got more and more dependencies

or it's sort of proper the Python project, got more and more dependencies, got more and more different version requirements,

updated much more frequently,

the sort of policy that Debian put in place or sort of the, I wouldn't say policy necessarily as as much in SMD. The the idea of how Python libraries should be managed that sort of largely was was tried to be made compatible with dev in's packaging requirements,

just broke down. So there was just a lot of institutionalized,

on lack of love, I guess, to the idea of having a statically compiled Python thing. That, I think, stood in the way much more than any technical problems because it's there's no technical reason why you couldn't do a bunch of things. On Linux, I guess there is a technical reason why you can't do certain things currently, but that is something that could very much be solved. I'm most talking about the idea that I think presently you cannot dynamically load a library out of memory.

I believe it has to go through the file system first to be able to load it on Linux, but I'm not entirely sure. So

there was actually, long time ago when Python x

were first created. You could actually bundle a c extension in Mac and load it from memory. The way it did it is it dumped out these the c DLL or the SO file or the to a temporary path and then loaded it from there. So there were there's already, like, a ton of plumbing for all of this sort of stuff hidden in in various parts of setup tools or or distutils

that could totally be used for making self contained,

things. But there was just no drive behind it in the community, I guess. And as far as I understand, this is changing now because it it's very, very popular now to, to have single, I would say, single file applications.

I I I credit

OS 10 a lot with this. And also the the fact that even people from the Python community are now building some command line executables in in Go, and and other languages

is, sort of a giveaway that the Python community will have to deal with this because clearly people which like Python choose other languages because they have the requirement to distribute, executable. I I'm in the same situation right now with Sentry where we we started building, a Sentry command line executable to manage certain things through the Sentry API, and I chose to write it in Rust,

because it's so easy to distribute an executable this way.

I also have to wonder if perhaps there's somewhat of a general sort of lack of love and effort in the larger Python community around packaging because we interviewed Donald Stuffed a few weeks ago on the Python packaging infrastructure and PIP and all of that. And they're doing some really great work, but they are just dying for contributors.

So I have to wonder if part of it has to do with that. People just don't consider that to be very sexy work to work on. I I I don't actually think it's that the people don't consider it sexy work. I think that people are actively hostile towards certain things. I've noticed this a long time. I was a super big supporter of Python x for a super long time, and setup tools. That was many, many, many years ago. And every time I brought it up, like, oh, we should we should like, I know it's crappy in how it works, but we should totally make this a thing. That was that was like, there were so many people who were

so loud against this idea of of making eggs into into a thing, and it took a really, really long time for them to become something. And in fact, x never became a big thing outside of certain tiny communities.

Only when the wheel format sort of replaced x, it it became all of a sudden, a sexy thing. And that is that is because

the the person who wrote the wheel specification,

I don't actually know who it was. Daniel Holt maybe. I don't know. He just ignored a lot of this this negative feedback that people brought on this thing before and just made a really good implementation of it and just convinced everyone by by just going ahead with implementing this. But I think there's a lot of hostility towards certain changes which is a little bit disappointing I guess. But that's that's just how the community works, and you have to just ignore it for a while, and and just show that it's actually not that bad. I I guess the the idea of just telling people that it's not bad, or conceptually not bad is is not enough. You have to also get the implementation right before people can warm up to the idea of something.

You've been pretty public about your opinions of Python 2 versus Python 3. I'm curious how your position subject has evolved over time as newer releases of Python 3 have come out. I don't know. I it's a it's a topic I don't care that much about anymore, I guess.

Practically,

I'm not using Python 3 because all the client work I'm doing is Python 2. Sentry is Python 2. So I I I'm not exposed to Python 3 as much anymore because for a while I was exposed to it because I had to port all my libraries to it. Now that they run on it, I just have to fix it up when it breaks again. My opinion is likely unchanged, I think. So there is 1 opinion, I guess, that has changed. My opinion on Unicode and Python 3 is now different than it was initially. I originally criticized Python 3 for the some of the decisions they made on Unicode in regards to how they represent certain APIs, like file systems and so forth. I still think that Python 3 chose the worst way possibly to implement Unicode. But what I originally had in mind for how Unicode should be evolved also probably wasn't quite right. So if I would do a Python screen now, I guess I would go down the go and thrust path. I would break the language in a way where you would say, actually,

we represent strings as UTF-eight.

That that's sort of how I would do this now. I I don't know if that answers the question. In regards to how I feel about Python 3, I guess it answers more how I feel about Unicode

now. That's different. It's tricky. Yeah. It's a complex and, long running,

issue. So, no, that's totally valid answer.

So let's talk about Lecter. What differentiates it from the pack, and what keeps you coming back to CMS projects?

So I don't know if it's CMS or if it's static file generator. It's something in between. The main reason I wrote it is because I wanted to just be able to make little tiny websites for projects and other things and have a database behind it, which is based on static files. I wanted to do this for a really long time. I just didn't have enough motivation to actually implement it. What I have now is, I think, quite good. There are some projects, I guess, which are doing something related to that.

There is, I think there's a bunch of PHP projects which are dabbling in this field, but most of them are still requiring PHP to run. It just dynamically loads things at 1 time. So what Lexus does differently, it it has a strong dependency management system behind it, which detects which files change and then builds up a new static website from it. I think it's very cool. I I like playing with it. There's some things which I would like to improve on it. But overall, I think for portfolio websites and stuff like this, it's a really good tool. And I I think it stands alone by its design. I don't think there are any projects where you can do this sort of stuff that you can do with it.

What are those kinds of things? You just said there aren't any other projects where you can do what you can do with it. What kinds of things are those?

So what makes like, interesting is that, basically, it has so I guess, you know, Django. So in Django, you define your models, and then you can have Python classes, and you can modify the data, and you can play around with the data you have, and you can generate out an admin interface. Lecter is similar to that where you have any files where you can define your data model that you have for your website. Like, let's say you have a section where you show projects. You have a section where you show your,

I don't know, a news blog post, something like this. So you define the data model of what you have, and then it generates an admin interface for you. But instead of storing it in a database, it stores it into static files on the file system. So you can track it with Dropbox, Git, something like this. I think that makes the device exciting because you have like, I grew a little bit like, I I do web for a really long time at this point. And 1 of the things that annoys me every 5 years is that I keep having stuff running, which is written in a technology, which requires active maintenance. And it's just a tedious task. It often ends up with you have to fix some security problems, so it just takes down the website because it's just too much work to keep this thing running. So I like the idea of just building

something which conceptually is so easy that you just build out a static HTML, and it runs for, like, a 100 years. Something like this.

I I don't think that lecture is the ultimate answer to have websites which will run for the for, like, forever.

I don't think it's there.

But I want to explore the idea more to build software which,

can be used to write things which live forever and not just for 5 years. Because I noticed that sort of the halftime of websites is dropping and not going up, which is okay for a lot of things which have active maintenance like Facebook, Reddit, that sort of stuff. But it it doesn't work as well for personal blogs, articles,

documentation,

this kind of thing. And that's that's why Lecter exists because I want something that can generate

good running static HTML. And conceptually, it doesn't need the database, just some static files.

I totally agree on on so many levels. I think, first of all, that the not requiring a database is huge. I mean, that's why I switched to a static generation platform for my blog because running a WordPress I'm sorry, WordPress.

Running a WordPress blog with the, you know, database requirement that it has, it increases the attack surface

exponentially

when you have to be running a website with this stuff. And as you say, it increases the fragility and increases the amount of active maintenance

that's required to keep it all humming with static

HTML. Like, you don't have to worry if you take a security update on your website because, you know, the SSL library has been patched or something else has been patched, that suddenly your database is gonna is gonna fall over and your whole website is gonna go down. It's just not an issue. As long as the web server stays up and it takes a lot to kill a web server, then you're good to go. Also, in terms of longevity, I really think that's an important point. And for those of us who are old enough to remember the earlier days of the web, there's an awful lot that's just not there anymore, and that's very frustrating.

There was this something awful. I think it was something awful webcomic that I really, really loved and I would reference every so often, basically sort of lampooning people who dress their pets in costumes.

It came up recently where I wanted to be able to post a link to that and it's it's just gone. I think people have this perception of the web as a as a semi permanent thing, but it's really not. And I think the more we can move to things that are more permanent, I think the better off we'll be. So that's great. Yeah. I think at least for some things, you don't need a dynamic system behind it. Like webcomics, for instance. There's no reason why that has to be. Like, xkcd does perfectly fine, without comments on on the webcomic and stuff like this. So just and and and comments, I mean, you can still sort of outsource to, like, discuss and co. But I think the the core content of the website doesn't need to be dynamic.

That's right. And if discuss and co go go away, then the comments will will vanish. But the core content will still be there. Yeah.

So since we're talking about static sites and blogging,

curious how you view your blogging as having contributed to the work that you do and the success that you have achieved, and also wondering

what your view is on the level of importance that blogging holds to somebody's overall career for somebody who may just be getting started in the software community?

Hard to answer. I think for me personally,

I I like I like writing stuff. I discovered it over the years more and more that I just like to bring thoughts to paper. I write many more things than I actually end up publishing. It's sort of a a really weird approach I have where I have a bunch of files sitting around with started things I want to write on. And most of them actually at all not related to programming. Some of them make it to my blog. Most of them just sit around on my hard drive waiting for me to go back to them and and do something with them eventually. It's it's sort of a way to deal with reality, I guess, is to just write it down, try to analyze it. I think that for me personally affects how I work just because a lot of things I do involve me

writing down my thoughts thoughts to paper. And it's sort of a way for me to to deal with complex problems as well, especially also problems not directly related to programming. So I guess out of that, it influenced me.

I don't think that blogging necessarily has a a positive contribution to programming other than that. I I don't think that having a blog has made me a better programmer

or or something like this. And I don't think that blogging in itself even is a a positive contribution. Basically, it's you write down your state of mind, and then people refer to it for many years. And it sort of brings some of your thoughts

much more gravitas

than than is appropriate, I guess. Like, people link to some old post of mine about Python 3, for instance, or about something else. And they they might have changed the meanings or there's at least there are different nuances to it. And and because you can always refer to this also, I think it's more interesting to see, like, how a person changes over time by reading the blog than to use it as a reference. I guess, in a way, that applies to anything that's written down. But with a blog, you sort of have the idea that it's not as serious, I guess, as a scientific paper. Right. Something like this. I I I like the process of writing stuff, sharing with other people. That's for sure. Sure. Yeah. With a blog, it's a good way to sort of share your thoughts, but it's also really easy to lose the context in which those thoughts were formed, particularly

as a blog post ages.

So there are certain types of content that will age well.

For instance, if it's just a purely technical item that just shows how to solve 1 problem. But even that can age because

the environment around that particular technical problem changes as new versions of libraries and new versions of languages come out. But particularly,

an exposition piece, for instance, on your thoughts on Python 3, as you said, your thoughts can change over time and also the context of those thoughts is very difficult to capture in a piece that is something that somebody will actually take the time to read, not to mention the amount of time that it would require to write if you were to actually include all of the tangential information.

So

as has been mentioned a couple of times already, you've been doing a fair amount of work with Rust recently. I'm wondering what your reasoning was for picking Rust as a language to learn in the first place and how that's influenced your work with Python.

So I find Rust to be the most exciting thing that happened to new things in programming since I can remember probably. There's nothing that excited me as much as Rust in in programming, mostly because it just I I already had the idea of how computer programs

should ideally work conceptually, I guess, which is sometimes hard to do in a language. And Rust

manifests that thinking process into a language that forces you to actually

adhere to these, ideas. And it it mostly evolves around the concept of ownership, I guess. So Rust forces you to do certain things which I believe are right. So and because I had this thinking process, not as, like, not in any way,

as properly formalized as Rust does it, I guess. It just excited me out of this.

And it was I guess, it struck a nerve for a lot of people, and it got a really good community behind it to evolve the language in ways that made it really exciting. And that's why I like it, I guess, as a language and as a as a community. I I don't think that Rust is the language to pick to build new projects

without consideration of what the project is about. I don't think many languages

can be that. I think Java might be 1 of those languages where I can say, like, no matter what you do, Java is the answer. I guess that that's kind kinda how you could do it, I guess, unless you write a computer game. But Rust is not that. There is there is certain things you can use Rust for. There are certain things you can't use Rust for, at least so far. It's just it's a very exciting language. It's a lot of fun to play around with. It has a really good ecosystem around it. That's what makes it exciting.

That's also why, I guess, it's more exciting to me than some other languages which are now popular just because it's so different.

Because very often with with other stuff that I'm using, I keep going back to Python because Python just might not be as sexy as some other things, but it has, like, all of the ecosystem around it. With Rust, I don't have the feeling that I have to go back to Python, not because ecosystem is so good there. It it isn't. But because it's just so much fun to use the language. And that's why I just play around with it all the time as as much as I can with different things. And I think Rust has a very bright future ahead when it gets certain things solved, which it currently doesn't have solved yet. And and I hope that more people will pick it up. It's the most practical experimental language, language, I would say. Yeah. It's definitely a language that has been interesting to me for a while as well.

And there have been a couple of times where I considered picking it up for

the creation of new projects. But because of the particular type of project that I was trying to use it in, it didn't have some of the necessary libraries And the amount of upfront investment that it would require to actually create those libraries was sufficient that I ended up just going back to Python. So I'm wondering what the level of interface is between Rust and Python and how easy it would be to, for instance, create a native extension using Rust and then tying it into,

Python library for the wrapper around it, some blur to, some of the c extensions?

So it's fairly straightforward. 1 of the goals of Rust is to interface really nicely with other things. It doesn't have a real runtime. It supports the CABI.

It can catch down panics at the DLL boundary.

So it it works really well for that. In regards to how much tooling there is from the community to make Rust and Python work, I don't know actually because that's not something I have actively,

investigated.

I have used Rust from Python,

but I only ever export 1 or 2 functions and then c types is good enough or or c f f I is good enough to do that. What frustrates me to no end is how shitty Python's packaging is for native extensions

that are a little bit more involved. So you end up with horrible setup of PI setups and that kind of stuff, which is very disappointing. And that sort of kills it all the time for me to do something in that field because you have to deal with this details and set up tools. It's layers and layers of very ugly codes that are in your way of getting a native extension built in in the concept of a Python project. So I don't know if someone has already played with this, but last time I was looking into it, the distribution was very, very hard. That's very disappointing.

So I don't doubt that the packaging is very difficult, but I I just wanna point out, as you said, 1 of Rust's goals is to be very easily callable from higher level languages. In fact, in the examples

in the in, I believe it's Steve,

Klabnick's

Rust book, it basically says,

here's how you call a Rust routine from Python, and it gives you a really simple set up example of building some, you know, stupid simple hello world thing in in Rust

and then calling it from Python,

and that's falling off a log easy. So this kind of obviates my next question because that's what I was kind of about to ask is and you've already answered it. But that really impressed me that the Rust folks would recognize that in order to be more useful, it needs to be easily called from higher level languages. I think that's just great. I think it's unfortunate that, like you say, the Python community hasn't sort of embraced that more and made that an easier way to go because, as you say, you know, people like you might not choose that because of the difficulty in packaging. For people who aren't Rust devotees to begin with, they might choose again something like Go because its packaging story is very easy, very simplistic. And although it's not really in the same league as Rust in the sense that it's garbage collected and doesn't have Rust's awesome ownership

and borrowing memory handling model. A lot of people perceive it as kinda living in the same space. I think there's there's a huge difference between Go, Rust, and Python. I think a lot of people see Rust as a I can use it as a replacement for c plus plus, and I could theoretically use it with Ruby, Python, and so forth. People see Go as a hybrid between Python and Java. It like, you don't write Go and you're not you don't combine Go and Python. You write your whole thing in Go. Like, Go doesn't even try to interface with other things. It's, it's tremendously bad at interfacing with other things. Even interfacing with c and go is, is a very,

like, more complex story.

I mean, it's possible. They have support for it. But if you look at how it's implemented, it's just it's, it's not beautiful, I would say. And it doesn't want to be. Go wants to be its own environment similar to to how many other things before it did it,

like I would say Java. So but Go is a very strong alternative to Python for many people. And I I know lots of people who are, for new projects, picking up Go as the default tool to use as a replacement for Python. That's sort of what I would say is sort of it's an interesting development to to see this because I I wouldn't have expected that sort of thing to be a replacement for Python for people. I I was always assuming that the replacement for Python would be Java,

JavaScript or another dynamic language. I wouldn't have expected it to be, a compiled language that is so low level in comparison.

Yeah. That's 1 of the things that really shocks me as well about this trend that you're referring to is when I have tried to pick up Go and I haven't written any sizable code base with it, as I'm trying to learn it, I sit there and think to myself, okay. I don't have to do memory management, but I'm effectively being forced down to the level of doing c programming. And 1 of the things that I love about Python to bring it back to, you know, home is the high level of abstraction with which it allows you to work. For me, that is where my brain

wants to live. And I guess people enjoy

that being sort of forced to think in these really discreet low level terms for certain things. But I don't. And it kinda surprises me, like, kinda like what you just said that so many people are diving into this with wild abandon. Because aside from the packaging and delivery story for Go, which is phenomenal, I don't particularly

have not thus far, let's just say that way, enjoyed working in the language.

Yeah. It's,

it's odd. Like, I don't enjoy Go as a programmer, I would say. I can see why it's interesting for a lot of people. I can see why it has a bright future. But I don't I don't find it more enjoyable than programming Java, for instance. What I always liked about Python, and that's sort of also its biggest curse, I guess, is that the dynamic nature in it allowed you to do certain things

which are just neat. And

in some ways, that is actually

a strong benefit. In in some, it also, I guess, is not. 1 of the things that Python does, which I is is interesting, is it exposes

some interpreter internals to you,

to do something interesting with.

So for instance, you can, at any point in time, get the interpreter frame to see what local variables are currently assigned and that sort of stuff, which from a performance point of view is ridiculous. Like, you wouldn't ever build something like this intentional. But that's just what the interpreter provided you with early on, and then people started building things around that sort of in quotes dependent on this. So it made it a slower language, but it also made it a language which was very exciting. Like, Sentry

started out as a as a project,

primarily, I would say, because you could get so much information out from the pipe interpreter. And that set up sort of the expectation that this is this is something

that's really interesting to have. This is something that makes it very possible to debug issues in production, which you wouldn't be able to do in certain other languages. Like, when you get a crash in Go, you get very little information. You would have to download the gigabyte crash dump to be able to explore what happened in your application. And and it's a very manual process. In Python,

if you get the trace back, you can, like, find out what any local variable was at that point. Like in Duxnet, for instance, there's a is a debugger middleware where you can execute

source codes in each stack frame to figure out more and more details about why something went wrong.

Sentry relies on, like, getting more and more information out of out of your crash as it happens.

And that allows you to do certain things that you just can't do in in Go. Like, you can write

a little bit, I would say, shitty code in in Python and and have it running for a long period of time. And then when it breaks, you can figure out why it broke. In many static languages, you have to do a lot of logging, a lot of defensive coding to be able to debug a complex interaction,

in in production

because you can't really you don't have an insight in this in this interpreter.

So I that just sets up different expectations. I would say for for web services,

Go is just not the right tool,

because you want this

ability to look into

what's what's happening, what's going wrong. Because they have so many video users,

they all do something on the same process. You want to

sort of dive into what an individual failure did. And I think it's just it's a very important

feature of Python that made it so

so useful,

in in in the field of web development in particular. And that is just just missing for me in Go. It doesn't excite me as much as a result. Yeah. I don't know. It's I I can see it being useful on web as well. Obviously, Google is doing it. Many people are doing it. But I think Go is a particularly well suited language for distributing

executables to to customers.

Bringing it back around to Poku, you mentioned that it was originally

formed as the container for a PHPBB

replacement that never saw the light. And recently, you've rebranded it to the Palettes project. So I'm wondering what inspired that rebranding and if the focus of that organization has changed.

So you have to see Buku as a historically grown thing, which is very hard to change over time, I guess. So when Georg and me started this PHPBB replacement project, that was just we bought a domain. We had a bunch of projects on it, and it just happened to be over time that there were a bunch of projects under an umbrella called.

There was never really like, that didn't intentionally happen. That just happened. What happened, I guess, over the last year is that I realized that Flask is way more popular than is healthy for a project that doesn't have a lot of management behind it. It rivals Strangle in at least popularity on GitHub, which is scarily significant, I would say. So I wanted to open up this

this lack of organization to be something that people can interact with. And I had a bunch of attempts, and it didn't really make sense. And then I decided that what what I actually want is I want people that are active in the community to get involved in the Flask related projects

independent

of whatever happened before. Like, have a clean slate. And that's what the Palettes project is. It's basically it's a website. Right now, it's only a website in the GitHub,

organization. But I have the hope that I can make a nonprofit organization, I guess, of some sort that could get donations to run server costs and stuff like this,

which might also be able to pay developers at 1 point. I need to look into the details. But the idea is at least to have something that doesn't have any historic legacy on it

where where projects can like, some sort of potential foundation.

And yeah. And and that's sort of how it started. So it's it's supposed to become an open organization where people can

work on those projects together, but open discussions about the future of it and why it doesn't have this weird history of what exactly is for who. Because that was never written down. It it just happened to be a thing.

So have you considered with regards to spawning your own not for profit project around this stuff, have you considered talking to the Python Software Foundation folks? Because I know they provide seed capital for important projects trying to get off the ground. And as you say, given Flask's GitHub popularity and just sort of its its popularity and mind share within the community, I don't think anybody would deny that Flask is a really important citizen in the Python nation.

I didn't think about it, and I don't want to think about it. The reason for that is this, because that will immediately give it more significance

than I want it to have. I don't want to say like, oh, I'm going to put a ton of my time behind making a flask foundation or something like this. Because I already have lots of things to do, and community maintenance and running a foundation was never part of of of what I signed up for, basically. And as it stands right now, it Flask doesn't cost me a lot of money a month. It's it's just the server costs. It's insignificant. So it doesn't need any capital to become something. What it actually needs is it needs people that are interested

in doing something. And and I was thinking that the the best way to

bootstrap something like this is just to see what the community wants

and then do what the community wants. Maybe maybe it will evolve into

something where I I was just playing around with City a couple of days ago. Maybe the most reasonable thing to do is to just ask if people are willing to come to some sort of informal conference, like a just tiny event, and see what does the community look like, who uses it. Is is there even demand for something like a like a foundation of sorts behind it? Because it's it's very hard for me to actually see who uses it, what is behind it,

because I never like, there was never a Chang'e Software Foundation. It was never a Flask conference, something like this. It just happened to grow in popularity, and I don't know what state is in. I want to see, basically, what's there, who is the community.

And and if the community wants, it can grow into something larger. If if there's no demand for it, then I don't have to do anything. That's all how I would see this.

So are there any other questions or topics that you'd like to mention before we move on?

No. I I I don't think so. I think hovers it all pretty well. Great. So for anybody who wants to follow you and see what you're up to and, keep track of any new projects that you come out with, what would be the best way for them to do that? I still use Twitter, I guess.

That's that's 1 way to see what I'm doing, my website, obviously. Yeah. Okay. So with that, I will move us on into the picks. For my pick this week, I'm gonna choose a video from 1 of the O'Reilly conferences.

I don't remember which 1 it is offhand. I think it might have been Cultivate. But it's a talk called Radical Candor.

And it's just a

interesting and

inspiring way to view

the role of managers and the way that you should approach

interacting with the people that you manage and work with. So definitely recommend taking a look at that, and I will pass it on to you, Chris.

Thanks. I have 2 picks this week. The first is a beer. It's from an Italian brewery called

Loverbeer, and the name of the beer is beer brugna.

It's a really delicious

sour. It's rare that I find a sour beer with this kind of depth. It's the only other sour with with the kind of depth that I've seen in, like, the Duchess de Bregenz. So it's it's really tasty. It's a great combination of of,

fruitiness and pucker inducing sour. It's it's just great stuff. My next pick is a game,

made by the Tomorrow Corporation, the folks who brought you Worlds of Goo and Little Inferno, and I just love their work.

It's a game called The Human Resource Machine,

and you manage this little dude who works in a giant office building,

managing inboxes and outboxes. And and basically to make this as short as I can,

that becomes

a metaphor for programming

effectively.

And you get assigned puzzles,

where you are manipulating the data going from the inbox to the outbox,

and along the way performing various operations in it. And what's super cool about it is it becomes, you know, in addition to sort of being programming, it's totally visual. You see little guy run around, grabbing

numbers out of the inbox, processing them, you know, maybe doing something with them on the carpet or whatever, and moving them to the outbox.

And as usual, because these folks are amazing,

it's just it's beautifully done.

It's totally addictive. I love it, and if I had kids, I would be throwing it at them.

That's it for me. Armin, what do you have for picks for us?

So since I it's very rare that I get the opportunity to to, like, promote certain really regional stuff.

So I come from a part, in Austria called Canton. It's like the southern part. In English, it's called Carinthia. And the there are not that many people living there. It's very rural. But they actually have a very nice microbrewery.

It's called Lancium.

I

think there are ways to buy some beer. I I know that they export it because there's, they only have 1 label in the back, and it says the name of the export on it. They have various different ones, and they're actually surprisingly good for coming from a tiny, tiny town. So you should give that a try. And also from the same area, there's a band called Mudd Acoustics.

And there's a 1 video I think I'll link to. It's called Highboden.

It's you can get an idea of of sort of what it's like to come from the rural Australian countryside,

and and that sort of music just with a modern twist to it.

Well, we really appreciate you taking the time out of your day to tell us about the work that you've done for the Python community and some of the projects you've been involved in. It's been a lot of fun. And I just want to thank you. You're welcome. Have

a

good day.

The Python Podcast.init

Summary

Brief Introduction

Interview with Armin Ronacher

Keep In Touch

Picks

Links

The Python Podcast.__init__