#410: Entering the Django core

Topics covered in this episode:

• Thoughts on Django’s Core
• futurepool
• Don't return named tuples in new APIs
• Ziglang: Migrating from AWS to Self-Hosting
• Extras
• Joke

About the show

Sponsored by us! Support our work through:

• Our courses at Talk Python Training
• The Complete pytest Course
• Patreon Supporters

Connect with the hosts

• Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky)
• Brian: @brianokken@fosstodon.org / @brianokken.bsky.social
• Show: @pythonbytes@fosstodon.org / @pythonbytes.fm (bsky)

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too.

Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.

Brian #1: Thoughts on Django’s Core

• Carlton Gibson
• Great discussion on
  • Django and Core vs Plugins
  • Sustainability with limited people
  • Keeping core small
  • The release cycle
  • eembrace plugins vs endorsing plugins.

Michael #2: futurepool

• via Pat Decker
• Takes the concept of multiprocessing Pool to the async/await world.

• Create a pool then delegate the work:

• I would LOVE to see something like this in a broader background asyncio worker pool concept.

• But that concept doesn’t exist in asyncio in Python and that’s a failing of the framework IMO.

Brian #3: Don't return named tuples in new APIs

• Brett Cannon
• First off, I’m grateful for any post that talks about APIs and the API is a module, class, or package API and not a Web/REST API. The term API existed long before the internet.
• “e.g., get_mouse_position() very likely has a two-item tuple of X and Y coordinates of the screen”
• “it actually makes your API more complex for both