Talk Python in Production(talkpython.fm)
talkpython.fm
Talk Python in Production
https://talkpython.fm/books/python-in-production
105 comments
Didn't yet go through the content, but having a AI generated image that you didn't even bother to at least touch-up a bit to fix the text does not give me a lot of confidence about the effort that went into this.
I came to this comment section to say exactly that.
At my work (university research lab) the Ph.D. students have to publish their thesis as a book to defend their degree. They are free to make the image for the cover, which is a very nice touch ang give you artistic freedom in what was supposed to be one of the most important moments of your career (I went for a picture of the chip I designed during my research).
For the past 3 years or so all we have are generic AI generated sciency-looking figures at the cover and it is depressing.
At my work (university research lab) the Ph.D. students have to publish their thesis as a book to defend their degree. They are free to make the image for the cover, which is a very nice touch ang give you artistic freedom in what was supposed to be one of the most important moments of your career (I went for a picture of the chip I designed during my research).
For the past 3 years or so all we have are generic AI generated sciency-looking figures at the cover and it is depressing.
Adds nothing, they could just picked a totally unrelated stock photo if they wanted to add something there. It just immediately halo effects the whole thing as something put together without effort. Stop doing this!
Isn't this overly critical ?. The content matters far more than the image and the chapters are good. I didn't even register the image - I think most folks today have eyes that auto-skip images after being pattern-trained to ignore ads.
The cover has a stack that says "ngirx", and it's all a smudgy mess.
"Don't judge a book by its cover" is for people who don't actually read books. You can't necessarily tell when a book is good based on its cover, but you can absolutely tell with a high certainty that a book with a lazy, crappy, low effort cover is probably going to have a similar level of care and attention put to the contents. It's easily at least a 95% hit rate. Is not overly critical to see something presented lazily and assume it will also be lazy inside, and in this kind of field, I'd also expect that if the cover is AI generated, most of the content could easily be as well.
"Don't judge a book by its cover" is for people who don't actually read books. You can't necessarily tell when a book is good based on its cover, but you can absolutely tell with a high certainty that a book with a lazy, crappy, low effort cover is probably going to have a similar level of care and attention put to the contents. It's easily at least a 95% hit rate. Is not overly critical to see something presented lazily and assume it will also be lazy inside, and in this kind of field, I'd also expect that if the cover is AI generated, most of the content could easily be as well.
With an image that is that poor quality, if it didn't matter then it would have been better not to include it.
Yes, but jumping to the conclusion that there would also be no effort in the text is a bit harsh. It's absolutely normal to set priorities.
It would have been less effort, and a better look, to have no image at all.
This isn't the first tab I've closed at the first sign of lazy AI usage and it probably won't be the last.
This isn't the first tab I've closed at the first sign of lazy AI usage and it probably won't be the last.
Thanks dude, the site is much more readable now.
"Don't judge a book by its cover" indeed (and litteraly in that case), but also "first impression matters".
In that case throwing a generated image without touch up shows the lack of care of the author for a work that's not as fleeting as a podcast. It's not that hard to type the correct words and/or a non wobbly font with Paint.NET / Photopea / Gimp / Affinity Photo / Photoshop / <your favorite pixel editor here>. It also shows an usage of AI without supervision which is kind of a red flag.
I used to listen to Michael Kennedy a lot when my day job was Python, and still occasionally do so this may get a pass, but it's still a bad signal in my books.
In that case throwing a generated image without touch up shows the lack of care of the author for a work that's not as fleeting as a podcast. It's not that hard to type the correct words and/or a non wobbly font with Paint.NET / Photopea / Gimp / Affinity Photo / Photoshop / <your favorite pixel editor here>. It also shows an usage of AI without supervision which is kind of a red flag.
I used to listen to Michael Kennedy a lot when my day job was Python, and still occasionally do so this may get a pass, but it's still a bad signal in my books.
I’m an occasional listener of the Talk Python podcast, and I’ve also taken Michael’s pytest course. It’s clear that he puts considerable effort into his content.
But there was no care in the images, which made me skeptical of the content. The free chapters are also poorly written. It reads like he dictated the content and didn't do a single review pass on it. The Docker Compose chapter especially is very light on details and doesn't explain how to use the various features and what tradeoffs or issues you may encounter. Like the AI images, the whole product feels rushed and haphazard and lacking in quality.
In which case it is very infuriating and sad. Honestly if he just did not put that AI art on every page, the whole thing would look way more serious. Presentation and first impression sadly do matter.
Put a pile of trash in a museum and people will think it's art, put art next to a pile of garbage and people will think it's trash.
These days I feel like a stick figure drawing in MS Paint even if crude denotes that an actual effort was made compared to "Generate an image of XYZ that includes blah blah blah..." sadly.
In my mind both are first steps to something more "proper" but one is at least hand-crafted artisan-ish compared to the other.
I have no qualms about using AI generated images as placeholder stuff or as a first step in an iterative process but when someone just slaps the image without the least bit of retouching it ends up looking kitsch.
In my mind both are first steps to something more "proper" but one is at least hand-crafted artisan-ish compared to the other.
I have no qualms about using AI generated images as placeholder stuff or as a first step in an iterative process but when someone just slaps the image without the least bit of retouching it ends up looking kitsch.
I think you're going to realize that as time passes and this becomes more normalized, your opinion is going to become the minority. That might be a good thing, or maybe not.
Thanks Ayhanfuat. I appreciate the comment. Yes, the image is AI generated, but the book and the content is not. I spent 9 months writing it. Cheers.
What about the content of the "conversations that bookend each chapter"? Are these real people giving their opinion that the second chapter is "fascinating" and that things "make sense" or is it AI-generated? If the latter, what's the point of presenting fake opinions?
Those "reader's briefs" are definitely AI. But they are discussed here a tad out of context. If you actually had the book and pull them down, the first track is me telling about them. It clearly says these are AI and just for fun, enjoy or skip. Here's the intro if you're interested:
https://blobs.talkpython.fm/00-readers-brief-intro.mp3?cache...
https://blobs.talkpython.fm/00-readers-brief-intro.mp3?cache...
but clearly he lapsed here and as a non-listener I immediately clicked out.
Hey Sean. I spent 9 months writing this book by hand. Yes the image is AI but the book is certainly not. You're definitely not obligated to read it, but I do want to comment that I put a ton of effort into the project.
Hi Mike! If you spent 9 months writing this book by hand, couldn't you do the courtesy of commissioning an artist to make you a cover image by hand as you clearly see the value of doing things by hand and not stealing the hard work of all the artists who have worked tirelessly to make art by hand only for AI to steal that work and for you to prompt it in seconds.
Put more effort into respecting other art forms and you might not get this reception next time.
Put more effort into respecting other art forms and you might not get this reception next time.
Just not enough to actually record a podcast, but generate a script and send it to an API to generate a (very recognisable) AI voiced podcast. It's literally called "Talk Python" with no humans talking.
Not sure if you're confusing with something else? "Talk Python to Me" is a long running podcast that has had a lot of definitely real humans on the show[0].
[0] https://talkpython.fm/
[0] https://talkpython.fm/
No, listen to the audio on the site originally attached. It's definitely AI.
I am as confident as possible that it's not- a lot of the guests are fairly known figures in the open source world (Wes McKinney, Charlie Marsh, Ned Batchelder) and video footage of the podcasts are available.
The podcast has also been going for several years, before it would have been possible to generate audio podcasts with AI.
The podcast has also been going for several years, before it would have been possible to generate audio podcasts with AI.
Joel, my podcast has been going for 10 years, I've done research and an interview nearly ever week over that time period resulting in over 500 episodes. It's not AI.
What you are referring to is the Readers' brief and you're taking it out of context. If you actually went to all of them, you would find this as the very first "track":
https://blobs.talkpython.fm/00-readers-brief-intro.mp3?cache...
It clearly explains that this is an extra to the book, it's created with AI and meant to be fun. It makes minor mistakes but enjoy it if you like or just don't listen and read the book without.
Here is the transcript from that opening track in case you don't want to listen:
Hello and welcome to the Reader's Brief for the Talk Python in Production book. This is your author, Michael Kennedy. I am thrilled you're interested in the book.
This companion audio series features short, exploratory conversations around each chapter of the book. They typically range from two and a half to four minutes per chapter. You can listen to each chapter's Reader's Brief just before reading a chapter to help you get in the ideal mindset. Or you can listen afterward and let your mind wander and expand on the ideas covered in the chapter. It's all up to you. Once I neared completion of the book, I had been brainstorming how I could offer an audio version. However, there are sufficiently many code listings that are too important to the content to really support a word-for-word audio book. It would be rough to listen to me narrate a Nginx configuration file to you, for example.
Thus, I came up with the reader's brief idea. A conversation around topics of each chapter in a brief two to four minute format that adds to the book rather than a traditional spoken true audio book. I do want to set expectations a bit. The reader's briefs are spoken by AI. Very good ones, by the way. So you will hear an occasional misspoken acronym such as Nginx or SSH. But enjoy these for what they are and don't expect perfection. They're really interesting ideas and background stories and thoughts on each chapter.
I hope you find that they add value to your experience. I know they did to mine. Finally, I have added the necessary metadata to the MP3 files. You should be able to add them all to your music library and they will appear in a single album. MP3 file for all the chapters together and put chapter markers in that MP3 file. Pick which one you want. Thanks for the interest in my book. I'll be with you page by page as you learn from it. Cheers.
What you are referring to is the Readers' brief and you're taking it out of context. If you actually went to all of them, you would find this as the very first "track":
https://blobs.talkpython.fm/00-readers-brief-intro.mp3?cache...
It clearly explains that this is an extra to the book, it's created with AI and meant to be fun. It makes minor mistakes but enjoy it if you like or just don't listen and read the book without.
Here is the transcript from that opening track in case you don't want to listen:
Hello and welcome to the Reader's Brief for the Talk Python in Production book. This is your author, Michael Kennedy. I am thrilled you're interested in the book.
This companion audio series features short, exploratory conversations around each chapter of the book. They typically range from two and a half to four minutes per chapter. You can listen to each chapter's Reader's Brief just before reading a chapter to help you get in the ideal mindset. Or you can listen afterward and let your mind wander and expand on the ideas covered in the chapter. It's all up to you. Once I neared completion of the book, I had been brainstorming how I could offer an audio version. However, there are sufficiently many code listings that are too important to the content to really support a word-for-word audio book. It would be rough to listen to me narrate a Nginx configuration file to you, for example.
Thus, I came up with the reader's brief idea. A conversation around topics of each chapter in a brief two to four minute format that adds to the book rather than a traditional spoken true audio book. I do want to set expectations a bit. The reader's briefs are spoken by AI. Very good ones, by the way. So you will hear an occasional misspoken acronym such as Nginx or SSH. But enjoy these for what they are and don't expect perfection. They're really interesting ideas and background stories and thoughts on each chapter.
I hope you find that they add value to your experience. I know they did to mine. Finally, I have added the necessary metadata to the MP3 files. You should be able to add them all to your music library and they will appear in a single album. MP3 file for all the chapters together and put chapter markers in that MP3 file. Pick which one you want. Thanks for the interest in my book. I'll be with you page by page as you learn from it. Cheers.
Thanks for the reply, unfortunately I've not heard of the podcast before, the only thing I see is the AI art and AI chat embedded on the page too. Just looked and sounded off. Appreciate that's not your intention, but it's how it looks to a person who's never heard of the podcast before.
Fair and thanks for the extra background info.
What? The interview podcast?
The sample that's on the site, it's definitely AI generated.
Listened to it and yeah... not only is the voice obvious AI, it drops an "It's not just X — it's Y" within the first 20 seconds. Copy-pasted straight from GPT.
Likely safe to assume that everything on this site is AI generated, including the book.
Likely safe to assume that everything on this site is AI generated, including the book.
If anyone else was confused, they're referring to the Audio Readers' Briefs. I didn't immediately recognize it as AI. To be honest the voice sounds exactly like my coworker responsible for doing our product video demonstrations.
I skipped through it and heard it pronounce nginx as en-gee-onix and only then did I realize it was fake.
I skipped through it and heard it pronounce nginx as en-gee-onix and only then did I realize it was fake.
Hi, see the reply to Joel just up this thread for more info on this. It is not presented as "real" it's clearly introduced as a fun AI extra.
You might want to mention this on the website as well, where it's definitely not clear. I also don't see how to navigate from the website to the introduction where it's explained.
That's a good point. I just redid the sample audio to include the opening section that adds that opening track that sets the stage with the positioning I put above.
I appreciate the idea.
I appreciate the idea.
You are not talking about the podcast, you might want to be a bit less straight in your claims it is.
I agree with everyone! Michael's name is a big stamp of "this will be high quality" for me, but if I didn't previously know that and saw an AI generated cover, there's a good chance I'd assume the content inside was AI generated slop, and might tune out without looking any further.
Thanks sort of Ben. :) The book is 100% human written over 9 months by me. The image is AI yes, but the book is not AI slop. It may be slop, but it's my slop if that's your assessment.
Haha, you're welcome sort of! :)
Love the podcast! I'm sure it isn't slop of any kind - I've really enjoyed reading your recent blog posts about Talk Python's web set up, so I'll definitely be giving it a read.
Love the podcast! I'm sure it isn't slop of any kind - I've really enjoyed reading your recent blog posts about Talk Python's web set up, so I'll definitely be giving it a read.
Thanks Ben, much appreciated.
Are you telling me that you haven't integrated granian and ngirx into your workflow?!
And you definitely don't want to miss "Web Arppss" running on "Limux"!
we've integrated granian into our stack at $WORK recently and couldn't be happier
It's good stuff. I've been running Granian for about a year and it's be a delight. I interviewed Giovanni (creator) on the podcast BTW.
I don't even understand why they do that, surely putting even a low quality something together would make it much better, and with actual font rendering.
Yeah, immediately off-putting, even though I actually enjoy the podcast. Not for like "AI bad" reasons, it's just ugly. Micheal, if you are reading this - please fix, it should take 5 minutes.
Agree, it tells me a lot if you are not willing to spend a couple hundred dollars to get a simple cover.
How many people who you hire for $100 will do this themselves without AI these days?
AI voice on podcast too, no thanks.
Hey Joel, please point to example of AI voices, especially sold as real, on the podcast.
I clicked on the link and was greeted by AI slop instantly. I checked the comments, saw this, am writing this and will probably not look at it ever again. Guess I am just not the target audience. I wish them that their AI slop strategy works out just for the sake of good vibes, though. If everyone does it it can't be bad, right? I'm the issue here, clearly.
ngirx and granian are my favorite technologies to work with! Completely agree, this trend of putting a completely useless and ugly AI image on top of your page, I despise. You could have searched the web for an actual diagram, if you wanted one here. These images provided negative values to your articles.
> ngirx and granian are my favorite technologies to work with!
I had the same initial thought, but I was skimming the page and came across this line:
> Then, see how to deploy a Flask+HTMX app via Granian, wire it into NGINX, and ensure automatic startups with systemd.
So I've just discovered that https://github.com/emmett-framework/granian exists...
I had the same initial thought, but I was skimming the page and came across this line:
> Then, see how to deploy a Flask+HTMX app via Granian, wire it into NGINX, and ensure automatic startups with systemd.
So I've just discovered that https://github.com/emmett-framework/granian exists...
You don't use ngirx in production? Do you even web scale, bro?
Chill dog
The idea of the book is to pull away a lot of the hype of big cloud providers, show practical steps how we run things over at Talk Python (podcast, courses, e-commerce, and more).I hope some of you find this refreshing!
You can read the first 1/3 online for free. The rest is available DRM free.
You can read the first 1/3 online for free. The rest is available DRM free.
Something is wrong with the js/css on the site - for everyone with dark mode the <strong> text is grey against white background - super hard to read.
The dark mode still has a white background so there's no reason to have it.
What are you talking about for dark mode on the site. There is no option to toggle the theme on the site. In the book, inside of readers like kindle on ipad, maybe.
But for the site as you mention, there is no dark mode. Is this some janky extension you use that isn't working? That's note the site's fault.
But for the site as you mention, there is no dark mode. Is this some janky extension you use that isn't working? That's note the site's fault.
If the user's OS and/or browser is set to dark mode. The site doesn't need to have a switch; its CSS has the media queries.
Ah, the change was so subtle I didn't realize it was happening. I updated the site so it's nice regardless of theme (dark/light) on the OS.
How much of the book is AI generated? Please be honest.
Zero percent of the text is AI generated. The image, yes, but I spent 9 months writing this book personally.
Amazing what a Hetzner dedi and docker compose can do
I recently compared AWS and Hetzner, not only in terms of raw compute costs but also by factoring in the personnel costs required for operation. I found this perspective particularly interesting: https://beuke.org/hetzner-aws/
Seems interesting, read the online summary. I am curious to read about your part on Chapter 14 (I am part of Litestar maintainer). Thank you for the book anyway !
Very cool Kumzy. Litestar is awesome, I interviewed some of the folks (you?) on the podcast. I give it some good press in that chapter.
You noted using persistent volumes for storing data, e.g.:
docker volume create umami-volume
Hey, you just run whatever backup command you would regularly do via compose.
For example, if you run `sqldump --db umami ...` in regular postgres (which is what they are using IIRC), then you run:
docker exec umami "sqldump --db umami ..."
Or something almost exactly like this (just from memory here and I wrote that script a year ago).
For example, if you run `sqldump --db umami ...` in regular postgres (which is what they are using IIRC), then you run:
docker exec umami "sqldump --db umami ..."
Or something almost exactly like this (just from memory here and I wrote that script a year ago).
Unrelated to the content: why on earth is super-light grey a good "bold" colour for a white background? I'm having to highlight each of the bolded parts of the text just to understand it :/
edit: console command for anyone else struggling to read this `document.documentElement.style.setProperty('--bulma-strong-color', '#000');`
edit: console command for anyone else struggling to read this `document.documentElement.style.setProperty('--bulma-strong-color', '#000');`
Is this some new trend where websites include @media (prefers-color-scheme: light) and @media (prefers-color-scheme: dark) in their css, but it just breaks the site?
This site doesn't even have two themes, that css is just there to break the bold text!
This site doesn't even have two themes, that css is just there to break the bold text!
Loads as a regular webpage for me (Safari, black font, white background).
The main text is black yes, but anything that's bold is light grey as per the CSS, which is near unreadable (even if you're not as colourblind as me I suspect)
Only if your system/browser is set to dark mode
Sorry all, I didn't realize this was happening. I don't use dark mode at the OS level, just per app. Fixed.
It only happens if you are using dark mode. That seems to be the only difference between light and dark mode on that site.
Haha, came here to mention the light grey text on white background as well. This is a great example of poor accessibility. It should be obvious to a human eye that this is bad; but in case it weren't, one could open up Chrome dev tools, find the styles for this text, click on the color picker, and observe that Chrome reports the contrast ratio for that text to be 1.17, whereas a comfortable (accessible) contrast ratio starts at 4.5.
"Have you heard the phrase "You're not Google, you're not Facebook, and you're not Netflix"? The TL;DR; is those tech giants that have 1M+ concurrent users. They have a hard requirement for no downtime."
Actually, one of the more interesting parts of the Google SRE book was that they don't try to aim for 0 downtime. They consider the background error rate of any network request and optimising much beyond this is counter productive.
Even for individual services they make a point of not trying to make them perfectly available, as this means downstream services are less likely to build in adequate provision for failure.
Actually, one of the more interesting parts of the Google SRE book was that they don't try to aim for 0 downtime. They consider the background error rate of any network request and optimising much beyond this is counter productive.
Even for individual services they make a point of not trying to make them perfectly available, as this means downstream services are less likely to build in adequate provision for failure.
I agree with this.
Those tech giants got to where they are by recognising specifically that they don't have "no downtime" requirements.
"Move fast and break things" isn't the mantra of companies with zero downtime requirements.
Those tech giants got to where they are by recognising specifically that they don't have "no downtime" requirements.
"Move fast and break things" isn't the mantra of companies with zero downtime requirements.
Choose how many nines you want. For most 99.9% availability is probably OK.
You can and probably should go thinner than this, with uv we effectively have a workflow comparable to deploying static binaries in other language stacks. You don't need the complexity of docker for this book's goal.
Was hoping the book would cover data persistence.
Was hoping the book would cover data persistence.
This go thin with uv is good advice for smaller projects. But as you grow with more aspects, it gets more problematic.
I ran code that way for years. But now we have 23 different services: web apps, APIs, and database servers, my code and other self-hosted services.
I would NOT run 23 projects/servers (3 versions of postgres) this way. Like so much, it depends. FWIW, the book goes into depth about these trade-offs.
I ran code that way for years. But now we have 23 different services: web apps, APIs, and database servers, my code and other self-hosted services.
I would NOT run 23 projects/servers (3 versions of postgres) this way. Like so much, it depends. FWIW, the book goes into depth about these trade-offs.
Could you please elaborate? Where do you run your apps?
Presumably just directly on whatever system they are using. If you have something that can be plopped on whatever linux distro and run reliably then you've already got what docker is supposed to give you.
Exactly as sibling comment says, e.g. let's pretend the popular httpx cli was my project to deploy and run on the server. With only uv installed, i can:
This caches the deps in an isolated virtual env for me. It'll only download the deps in the first run.
uv tool run "httpx[cli] @ git+https://github.com/encode/httpx"
This caches the deps in an isolated virtual env for me. It'll only download the deps in the first run.
I'm glad to see people recognizing that computers are quite fast and that they don't need massive cloud-scale solutions for simple problems. That being said, Python really shines as glue code and in small scripts where performance doesn't matter. You'll see considerable performance (and likely maintainability) gains by moving off of Python to almost any other language.
I don't know, but the "Read Online" button leads me to "https[://]talkpython.fm/books/python-in-production/#read-online", and that URL then tries to redirect to "https[://]talkpython.fm/books/python-in-production#read-online". (Notice how the last slash of the path is missing).
This forced my browser to reload the page, and it beats the entire purpose of anchoring and fragment-based navs.
This forced my browser to reload the page, and it beats the entire purpose of anchoring and fragment-based navs.
Is there a catch in "It's 6x cheaper than DO and a whopping 20x cheaper than Azure" or are most companies I know getting ripped off?
Depends on which $$s go into that comparison. Server costs? Probably. Engineering time? Accounting for all kinds of risks? Unlikely.
I don't think I've seen a cloud-first company that spent less engineering time on managing their infrastructure. You just replace one set of work with another.
Sometimes it results in more work because of the lowered upfront cost of spinning up new cloud services
Those numbers bother me. What does it mean to be "6x cheaper"? Is that a sixth the price? If something costs $100, what is 6x cheaper than it? 2x cheaper? 1x cheaper?
It is as frustrating as when people use "200% faster" to mean exactly the same thing as "twice as fast", and "100% faster" to mean the same thing.
It is as frustrating as when people use "200% faster" to mean exactly the same thing as "twice as fast", and "100% faster" to mean the same thing.
See my comment above. In the book, I "show my work" on the math.
Oh sure, I just mean that wording in particular. 1/6 the cost is clear to me, 6x cheaper is not, because the wording implies that there's some base point that the original price is the "1x cheaper" base point. Like what is 1x cheaper than the base price? The wording is confusing. Then there's the comparative. Is "6x cheaper" the same as "6x as cheap"? Logic says that 6x cheaper would be the same as 7x as cheap, but many very smart people use these interchangeably. Again, like when people say "3x faster" to mean "3x as fast" which means that "50% faster" is actually slower than the reference speed.
It's just a wording annoyance that always gets to me, so it's not a big deal. I always prefer "x% as fast" and "x% the price", because they're largely unambiguous.
It's just a wording annoyance that always gets to me, so it's not a big deal. I always prefer "x% as fast" and "x% the price", because they're largely unambiguous.
Yes, they are being ripped off.
A 8 CPU / 16 GB Ram server at Hetzner is $30 or so per month. It's $200+ at AWS / Azure.
Bandwidth is 4TB included from free at Hetzner, it's $92.16 / TB or $368.64 additional at AWS / Azure.
That is where the 6x comes from. It's described in detail with that math in the book BTW.
A 8 CPU / 16 GB Ram server at Hetzner is $30 or so per month. It's $200+ at AWS / Azure.
Bandwidth is 4TB included from free at Hetzner, it's $92.16 / TB or $368.64 additional at AWS / Azure.
That is where the 6x comes from. It's described in detail with that math in the book BTW.
A lot are getting ripped off. To what degree depends on their tech capabilities and business savvy (i.e. what would it cost them to do it themselves and what kind of discount can they negotiate from the cloud provider. If you're paying the listed rates you are getting ripped of).
At which monthly spend should we negotiate with AWS for example? And will they check if we are using 25 of their services instead of easily migratable VM-hosted apps?
Thanks for describing your experience with Granian. I have stuck with Gunicorn and Uvicorn so far but am now motivated to try the newer alternative.
Nice. I used uwsgi -> gunicorn -> gunicorn with uvworkers -> granian. Granian is great. While not crazy popular along, it's really based on Rust's Hyper, see https://crates.io/crates/hyper Hyper has 400M downloads so safe to say it's pretty battle tested.
I interviewed the creator of Granian on Talk Python BTW.
I interviewed the creator of Granian on Talk Python BTW.
Ironically what is styled as <strong> </strong> is very hard to read as its almost the same color as the background.
The book needs to remove the AI images. They are actively hurting the eyes with the wrong and weird perspective.
It is pretty light reading, name dropping a lot of software without going into details.
As always with Python: These books do not tell you the downsides, and the future of Python is uncertain because the governance has been taken over by a bunch of mediocre weirdos. Python core has always suffered from the problem that occasionally smart people implement something and then leave, but the majority of core devs are pretty dumb and they can now vote in their own after van Rossum left.
It is pretty light reading, name dropping a lot of software without going into details.
As always with Python: These books do not tell you the downsides, and the future of Python is uncertain because the governance has been taken over by a bunch of mediocre weirdos. Python core has always suffered from the problem that occasionally smart people implement something and then leave, but the majority of core devs are pretty dumb and they can now vote in their own after van Rossum left.