Dive into an insightful discussion about Django’s core and sustainability as it nears its 20th anniversary. Discover how the balance between core features and the plugin ecosystem shapes the framework's future. Explore exciting concepts like futurepool for async programming, and hear a humorous take on the quirks of web frameworks. The hosts also navigate the challenges of keeping a community engaged across various platforms while sharing their personal Python programming adventures.
The podcast emphasizes the importance of balancing Django's core framework stability with the vibrant ecosystem of community-driven plugins for enhanced functionality.
A new library, Future Pool, addresses challenges in AsyncIO by managing concurrency, thus improving application stability in asynchronous programming.
Deep dives
Transitioning Social Media Platforms
The discussion highlights the growing engagement on social media platforms like Blue Sky and Mastodon, emphasizing the importance of adapting to user preferences. Both hosts express their enjoyment of Blue Sky, contrasting it with their experiences on Mastodon, particularly in terms of user interface and accessibility. They mention the absence of an editing feature in Blue Sky, prompting a lighthearted acknowledgment of the potential for typos in posts. This community-oriented approach encourages listeners to engage with the podcast on these platforms, fostering a sense of connection among users.
Django's Core versus Plugins
The conversation delves into Django's core framework and its plugin ecosystem, exploring the balance between integrated features and community-driven enhancements. An article by Carlton Gibson outlines challenges related to maintaining a robust core while enabling plugins to flourish, as the ecosystem thrives on third-party packages. The hosts cite the long history of Django and underscore the significance of understanding its development dynamics, where adding features to the core can be complex and slow. They provide examples of popular plugins, highlighting that the vitality of Django lies not only in its core functionality but also in the diverse array of extensions available to developers.
Introducing Future Pool for AsyncIO
The podcast examines a new library that facilitates multiprocessing within an AsyncIO context, addressing the unique challenges presented by asynchronous programming. AsyncIO's inherent behavior of processing tasks without back pressure can overwhelm systems, and the Future Pool aims to streamline concurrency management. By allowing developers to limit the number of concurrent tasks, this library enhances application stability and performance. The conversation acknowledges the limitations of the Future Pool and suggests the need for more comprehensive solutions that could provide broader applicability across different programming scenarios.
Navigating API Design Choices
An article by Brett Cannon serves as a reminder about the complexities of using named tuples in API design, as they introduce access ambiguity between index-based and named access. While named tuples can enhance readability, they may inadvertently lead to confusion or misuse, especially when developers rely on both access patterns. Alternatives such as data classes and simple namespaces are suggested to improve code clarity and ergonomics. The discussion emphasizes prioritizing overall code quality and maintainability over shortening implementation time, advocating for thoughtful design decisions in API development.
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.
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 you and your users to use. For you, it doubles the data access API surface for your return type as you have to now support index-based and attribute-based data access forever (or until you choose to break your users and change your return type so it doesn't support both approaches)”
“… you probably don't want people doing with your return type, like slicing, iterating over all the items …”
Alternatives
class
dataclass
dictionary
TypedDict
SimpleNamespace
“My key point in all of this is to prefer readability and ergonomics over brevity in your code. That means avoiding named tuples except where you are expanding to tweaking an existing API where the named tuple improves over the plain tuple that's already being used.”