Planet Python

Last update: October 09, 2025 09:43 PM UTC

October 09, 2025

Everyday Superpowers

Why I switched from HTMX to Datastar

<span hx-target="#rebuild-bundle-status-button"
      hx-select="#rebuild-bundle-status-button"
      hx-swap="outerHTML"
      hx-trigger="click"
      hx-get="/rebuild/status-button"></span>

<span data-on-click="@get('/rebuild/status-button')"></span>

<div>
   <div id="alert"></div>
    <button hx-get="/info" 
            hx-select="#info-details" 
            hx-swap="outerHTML"
            hx-select-oob="#alert">
        Get Info!
    </button>
</div>

<div>
    <div id="alert"></div>
    <button id="info-details"
     data-on-click="@get('/info')">
        Get Info!
    </button>
</div>

<p id="info-details">These are the details you are looking for…</p>
<div id="alert">Alert! This is a test.</div>

<!-- info-component-placeholder.html -->
<div id="info-component">
    <button data-on-click="@get('/product/{{product.id}}/info')">
        Get Info!
    </button>
</div>

<!-- info-component-get.html -->
<div id="info-component">
    {% if alert %}<div id="alert">{{ alert }}</div>{% endif %}
    <p>{{product.additional_information}}</p>
</div>

<form id="purchase-item"
      data-on-submit="@post('/add-item', {contentType: 'form'})">"
>
  <input type=hidden name="cart-id" value="{{cart.id}}">
  <input type=hidden name="item-id" value="{{item.id}}">
  <fieldset>
    <button data-on-click="$quantity -= 1">-</button>
    <label>Quantity
      <input name=quantity type=number data-bind-quantity value=1>
    </label>
    <button data-on-click="$quantity += 1">+</button>
  </fieldset>
  <button type=submit>Add to cart</button>
  {% if msg %}
    <p class=message>{{msg}}</p>
  {% endif %}
</form>

<div id="cart-count">
    <svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">
        <use href="#shoppingCart">
    </svg>
    {{count}}
</div>

from datastar_py.consts import ElementPatchMode
from datastar_py.django import (
    DatastarResponse,
    ServerSentEventGenerator as SSE,
)

def add_item(request):
    # skipping all the important state updates
	return DatastarResponse([
		SSE.patch_elements(
    		render_to_string('purchase-item.html', context=dict(cart=cart, item=item, msg='Item added!'))
		),
		SSE.patch_elements(
    		render_to_string('cart-count.html', context=dict(count=item_count))
		),
	])

October 09, 2025 04:37 PM UTC

Mike Driscoll

An /intro to Python 3.14’s New Features

Python 3.14 came out this week and has many new features and improvements. For the full details behind the release, the documentation is the best source. However, you will find a quick overview of the major changes here. As with most Python releases, backwards compatibility is rarely broken. However, there has been a push to […]

The post An /intro to Python 3.14’s New Features appeared first on Mouse Vs Python.

October 09, 2025 12:05 PM UTC

October 08, 2025

Real Python

Python 3.14: Cool New Features for You to Try

Learn what's new in Python 3.14, including an upgraded REPL, template strings, lazy annotations, and subinterpreters, with examples to try in your code.

October 08, 2025 02:00 PM UTC

Quiz: Python 3.14: Cool New Features for You to Try

In this quiz, you'll test your understanding of the new features introduced in Python 3.14. By working through this quiz, you'll review the key updates and improvements in this version of Python.

October 08, 2025 12:00 PM UTC

October 07, 2025

PyCoder’s Weekly

Issue #703: PEP 8, Error Messages in Python 3.14, splitlines(), and More (Oct. 7, 2025)

October 07, 2025 07:30 PM UTC

Python Morsels

Python 3.14's best new features

Python 3.14 includes syntax highlighting, improved error messages, enhanced support for cocurrency and parallelism, t-strings and more!

Table of contents

1. Very important but not my favorites
2. Python 3.14: now in color!
3. My tiny contribution
4. Beginner-friendly error messages
5. Tab completion for import statements
6. Standard library improvements
7. Cleaner multi-exception catching
8. Concurrency improvements
9. External debugger interface
10. T-strings (template strings)
11. Try out Python 3.14 yourself

Read the full article: https://www.pythonmorsels.com/python314/

October 07, 2025 04:08 PM UTC

Real Python

What's New in Python 3.14

Covers Python 3.14's key changes: free-threading, subinterpreters, t-strings, lazy annotations, new REPL features, and improved error messages.

October 07, 2025 02:00 PM UTC

Seth Michael Larson

Is the "Nintendo Classics" collection a good value?

October 07, 2025 12:00 AM UTC

October 06, 2025

Ari Lamstein

Visualizing 25 Years of Border Patrol Data with Python

I recently had the chance to speak with a statistician at the Department of Homeland Security (DHS) about my Streamlit app that visualizes trends in US Immigration Enforcement data (link). Our conversation helped clarify a question I’d raised in an earlier post—one that emerged from a surprising pattern in the data. A Surprising Pattern The […]

October 06, 2025 03:30 PM UTC

Real Python

It's Almost Time for Python 3.14 and Other Python News

The final release of Python 3.14 is almost here! Plus, there's Django 6.0 alpha, key PEP updates, PSF board results, and fresh Real Python resources.

October 06, 2025 02:00 PM UTC

Brian Okken

pytest 2.6.0 release

There’s a new release of pytest-check. Version 2.6.0.

This is a cool contribution from the community.

The problem

In July, bluenote10 reported that check.raises() doesn’t behave like pytest.raises() in that the AssertionError returned from check.raises() doesn’t have a queryable value.

Example of pytest.raises():

with pytest.raises(Exception) as e:
    do_something()
assert str(e.value) == "<expected error message>"

We’d like check.raises() to act similarly:

with check.raises(Exception) as e:
    do_something()
assert str(e.value) == "<expected error message>"

But that didn’t work prior to 2.6.0. The issue was that the value returned from check.raises() didn’t have any .value atribute.

October 06, 2025 01:30 PM UTC

Talk Python to Me

#522: Data Sci Tips and Tricks from CodeCut.ai

Today we’re turning tiny tips into big wins. Khuyen Tran, creator of CodeCut.ai, has shipped hundreds of bite-size Python and data science snippets across four years. We dig into open-source tools you can use right now, cleaner workflows, and why notebooks and scripts don’t have to be enemies. If you want faster insights with fewer yak-shaves, this one’s packed with takeaways you can apply before lunch. Let’s get into it.

October 06, 2025 08:00 AM UTC

Rodrigo Girão Serrão

Functions: a complete reference | Pydon't 🐍

This article serves as a complete reference for all the non-trivial things you should know about Python functions.

Functions are the basic building block of any Python program you write, and yet, many developers don't leverage their full potential. You will fix that by reading this article.

Knowing how to use the keyword def is just the first step towards knowing how to define and use functions in Python. As such, this Pydon't covers everything else there is to learn:

• How to structure and organise functions.
• How to work with a function signature, including parameter order, *args and **kwargs, and the special syntax introduced by * and /.
• What anonymous functions are, how to define them with the keyword lambda, and when to use them.
• What it means for functions to be objects and how to leverage that in your code.
• How closures seem to defy a fundamental rule of scoping in Python.
• How to leverage closures to create the decorator pattern.
• What the keyword yield is and what generator functions are.
• What the keyword async is and what asynchronous functions are.
• How partial function application allows you to create new functions from existing functions.
• How the term “function” is overloaded and how you can create your own objects that behave like functions.

What goes into a function and what doesn't

Do not overcrowd your functions with logic for four or five different things. A function should do a single thing, and it should do it well, and the name of the function should clearly tell you what your function does.

If you are unsure about whether some piece of code should be a single function or multiple functions, it's best to err on the side of too many functions. That is because a function is a modular piece of code, and the smaller your functions are, the easier it is to compose them together to create more complex behaviours.

Consider the function process_order defined below, an exaggerated example that breaks these best practices to make the point clearer. While it is not incredibly long, it does too many things:

def process_order(order):
    # Validate the order:
    for item, quantity, price in order:
        if quantity <= 0:
            raise ValueError(f"Cannot buy 0 or less of {item}.")
        if price <= 0:
            raise ValueError(f"Price must be positive.")

    # Write the receipt:
    total = 0
    with open("receipt.txt", "w") as f:
        for item, quantity, price in order:
            # This week, yoghurts and batteries are on sale.
            if "yoghurt" in item:
                price *= 0.8
            elif "batteries" in item:
                price *= 0.5
            # Write this line of the receipt:
            partial = price * quantity
            f.write(f"{item:>15} --- {quantity:>3}...

October 06, 2025 07:00 AM UTC

October 05, 2025

Paolo Melchiorre

Django: one ORM to rule all databases 💍

Comparing the Django ORM support across official database backends, so you don’t have to learn it the hard way.

October 05, 2025 10:00 PM UTC

Christian Ledermann

Python Code Quality Tools Beyond Linting

The landscape of Python software quality tooling is currently defined by two contrasting forces: high-velocity convergence and deep specialization. The recent, rapid adoption of Ruff has solved the long-standing community problem of coordinating dozens of separate linters and formatters, establishing a unified, high-performance axis for standard code quality.

A second category of tools continues to operate in necessary, but isolated, silos. Tools dedicated to architectural enforcement and deep structural metrics, such as:

• import-linter (Layered architecture enforcement)
• tach (Dependency visualization and enforcement)
• complexipy, radon, lizard (Metrics for overall and cognitive complexity)
• module_coupling_metrics, lcom, and cohesion (Metrics for coupling and class cohesion)
• pyscn - Python Code Quality Analyzer (Module dependencies, clone detection, complexity)

These projects address fundamental challenges of code maintainability, evolvability, and architectural debt that extend beyond the scope of fast, stylistic linting. The success of Ruff now presents the opportunity to foster a cross-tool discussion focused not just on syntax, but on structure.

Specialized quality tools are vital for long-term maintainability and risk assessment. Tools like import-linter and tach mitigate technical risk by enforcing architectural rules, preventing systemic decay, and reducing change costs. Complexity and cohesion metrics from tools such as complexipy, lcom, and cohesion quantitatively flag overly complex or highly coupled components, acting as early warning systems for technical debt. By analysing the combined outputs, risk assessment shifts to predictive modelling: integrating data from individual tools (e.g., import-linter violations, complexipy scores) creates a multi-dimensional risk score. Overlaying these results, such as identifying modules that are both low in cohesion and involved in tach-flagged dependency cycles, generates a "heat map" of technical debt. This unified approach, empirically validated against historical project data like bug frequency and commit rates can yield a predictive risk assessment. It identifies modules that are not just theoretically complex but empirically confirmed sources of instability, transforming abstract quality metrics into concrete, prioritized refactoring tasks for the riskiest codebase components.

Reasons to Connect

Bring the maintainers and core users of these diverse tools into a shared discussion.

Increasing Tool Visibility and Sustainability: Specialized tools often rely on small, dedicated contributor pools and suffer from knowledge isolation, confining technical debate to their specific GitHub repository. A broader discussion provides these projects with critical outreach, exposure to a wider user base, and a stronger pipeline of new contributors, ensuring their long-term sustainability.

Let's start the conversation on how to 'measure' maintainable, and architecturally sound Python code.
And keep Goodhart's law: "When a measure becomes a target, it ceases to be a good measure" in mind ;-)

October 05, 2025 02:07 PM UTC

Daniel Roy Greenfeld

Using pyinstrument to profile Air apps

Quick instructions for a drop-in Air middleware for identifying performance bottlenecks in Air apps

October 05, 2025 08:00 AM UTC

Graham Dumpleton

Lazy imports using wrapt

PEP 810 (explicit lazy imports) was recently released for Python. The idea with this PEP is to add explicit syntax for implementing lazy imports for modules in Python.

lazy import json

Lazily importing modules in Python is not a new idea and there have been a number of packages available to achieve a similar result, they just lacked an explicit language syntax to hide what is actually going on under the covers.

When I saw this PEP it made me realise that a new feature I added into wrapt for upcoming 2.0.0 release can be used to implement a lazy import with little effort.

For those who only know of wrapt as being a package for implementing Python decorators, it should be known that the ability to implement decorators using the approach it does, was merely one outcome of the true reason for wrapt existing.

The actual reason wrapt was created was to be able to perform monkey patching of Python code.

One key aspect of being able to monkey patch Python code is to be able to have the ability to wrap target objects in Python with a wrapper which acts as a transparent object proxy for the original object. By extending the object proxy type, one can then intercept access to the target object to perform specific actions.

For the purpose of this discussion we can ignore the step of creating a custom object proxy type and look at just how the base object proxy works.

import wrapt

import graphlib

print(type(graphlib))

print(id(graphlib.TopologicalSorter), graphlib.TopologicalSorter)

xgraphlib = wrapt.ObjectProxy(graphlib)

print(type(xgraphlib))

print(id(graphlib.TopologicalSorter), xgraphlib.TopologicalSorter)

In this example we import a module called graphlib from the Python standard library. We then access from that module the class graphlib.TopologicalSorter and print it out.

When we wrap the same module with an object proxy, the aim is that anything you could do with the original module, could also be done via the object proxy. The output from the above is thus:

<class 'module'>
35852012560 <class 'graphlib.TopologicalSorter'>
<class 'ObjectProxy'>
35852012560 <class 'graphlib.TopologicalSorter'>

verifying that in both cases the TopologicalSorter is in fact the same object, even though for the proxy the apparent type is different.

The new feature which has been added for wrapt version 2.0.0 is a lazy object proxy. That is, instead of passing to the object proxy when created the target object to be wrapped, you pass a function, with this function being called to create or otherwise obtain the target object to be wrapped, the first time the proxy object is accessed.

Using this feature we can easily implement lazy module importing.

import sys
import wrapt

def lazy_import(name):
    return wrapt.LazyObjectProxy(lambda: __import__(name, fromlist=[""]))

graphlib = lazy_import("graphlib")

print("sys.modules['graphlib'] =", sys.modules.get("graphlib", None))

print(type(graphlib))

print(graphlib.TopologicalSorter)

print("sys.modules['graphlib'] =", sys.modules.get("graphlib", None))

Running this the output is:

sys.modules['graphlib'] = None
<class 'LazyObjectProxy'>
<class 'graphlib.TopologicalSorter'>
sys.modules['graphlib'] = <module 'graphlib' from '.../lib/python3.13/graphlib.py'>

One key thing to note here is that when the lazy import is setup, no changes have been made to sys.modules. It is only later when the module is truly imported that you see an entry in sys.modules for that module name.

Some lazy module importers work by injecting into sys.modules a fake module object for the target module. This has to be done right up front when the application is started. Because the fake entry exists, when import is later used to import that module it thinks it has already been imported and thus what is added into the scope where import is used is the fake module, with the actual module not being imported at that point.

What then happens is that when code attempts to use something from the module, an overridden __getattr__ special dunder method on the fake module object gets triggered, which on the first use causes the actual module to then be imported.

That sys.modules is modified and a fake module added is one of the criticisms one sees about such lazy module importers. That is, the change they make is global to the whole application which could have implications such as where side affects of importing a module are expected to be immediate.

With the way the wrapt example works above, no global change is required to sys.modules, and instead impacts are only local to the scope where the lazy import was made.

Reducing the impacts to just the scope where the lazy import was used is actually one of the goals of the PEP. The example using wrapt shows that it can be done, but it means you can't use an import statement, but then that is what the PEP aims to still allow, albeit they still require a new lazy keyword for when doing the import. Either way, the code where you want to have a lazy import needs to be different.

The other thing which the PEP should avoid is the module reference in the scope where the module is imported being any sort of fake module object. Initially the module reference would effectively be a place holder, but as soon as used, the actual module would be imported and the place holder replaced.

For the wrapt example the module reference would always be a proxy object, although technically with a bit of stack diving trickey you could also replace the module reference with the actual module as a side effect of the first use. This sort of trick is left as an exercise for the reader.

October 05, 2025 12:00 AM UTC

October 04, 2025

Paolo Melchiorre

My DjangoCon US 2025

A summary of my experience at DjangoCon US 2025 told through the posts I published on Mastodon during the conference.

October 04, 2025 10:00 PM UTC

Rodrigo Girão Serrão

TIL #134 – = alignment in string formatting

Today I learned how to use the equals sign to align numbers when doing string formatting in Python.

There are three main alignment options in Python's string formatting:

However, numbers have a fourth option =. On the surface, it looks like it doesn't do anything:

x = 73

print(f"@{x:10}@")   # @        73@
print(f"@{x:=10}@")  # @        73@

But that's because = influences the alignment of the sign. If I make x negative, we already see something:

x = -73

print(f"@{x:10}@")   # @       -73@
print(f"@{x:=10}@")  # @-       73@

So, the equals sign = aligns a number to the right but aligns its sign to the left. That may look weird, but I guess that's useful if you want to pad a number with 0s:

x = -73

print(f"@{x:010}@")  # @-000000073@

In fact, there is a shortcut for this type of alignment, which is to just put a zero immediately to the left of the width when aligning a number:

x = -73

print(f"@{x:010}@")  # @-000000073@

The zero immediately to the left changes the default alignment of numbers to be = instead of >.

October 04, 2025 02:01 PM UTC

October 03, 2025

Luke Plant

Breaking “provably correct” Leftpad

Why? Because it’s fun.

October 03, 2025 08:00 PM UTC

Mariatta

Disabling Signup in Django allauth

Django allauth

Django allauth is a popular third party package that provides a lot of functionality for handling user authentication, with support for social authentication, email verification, multi-factor authentication, and more.

It is a powerful library that greatly expands the built-in Django authentication system. It comes with its own basic forms and models for user registration, login, logout, and password management.

I like using it because often I just wanted to get a new Django project up and running quickly without having to write up all the authentication-related views, forms, and templates myself. I’m using django-allauth in PyLadiesCon Portal, and in my personal project Secret Codes.

October 03, 2025 07:50 PM UTC

Real Python

The Real Python Podcast – Episode #268: Advice on Beginning to Learn Python

What's changed about learning Python over the last few years? What new techniques and updated advice should beginners have as they start their journey? This week on the show, Stephen Gruppetta and Martin Breuss return to discuss beginning to learn Python.

October 03, 2025 12:00 PM UTC

October 01, 2025

Real Python

Python 3.14 Preview: Better Syntax Error Messages

Python 3.14 includes ten improvements to error messages, which help you catch common coding mistakes and point you in the right direction.

October 01, 2025 02:00 PM UTC

Django Weblog

Django security releases issued: 5.2.7, 5.1.13, and 4.2.25

In accordance with our security release policy, the Django team is issuing releases for Django 5.2.7, Django 5.1.13, and Django 4.2.25. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

October 01, 2025 01:55 PM UTC

Real Python

Quiz: Python 3.14 Preview: Better Syntax Error Messages

Explore how Python 3.14 improves error messages with clearer explanations, actionable hints, and better debugging support for developers.

October 01, 2025 12:00 PM UTC

• • Full content
  • RSS feed
  • Powered by Planet!
• Python Libraries
  • Planet OLPC
  • Planet PySoy
  • Planet SciPy
  • Planet Twisted
• Python/Web Planets
  • Planet CherryPy
  • Django Community
  • Planet Plone
  • Planet Turbogears
• Other Languages
  • Planet Lisp
  • Planet Parrot
  • Planet Perl
  • Planet Ruby
• Subscriptions
  • [OPML feed]
  • "Menno's Musings"
  • "Michael J.T. O'Kelly"
  • "Michael Kennedy's Thoughts on Technology"
  • "Morphex's Blogologue"
  • "Speno's Pythonic Avocado"
  • "William's Journal"
  • 2degrees
  • A. Jesse Jiryu Davis
  • ABlog for Sphinx
  • Aahz
  • Abhijeet Pal
  • Abu Ashraf Masnun
  • Adam Pletcher
  • Adrarsh Divakaran
  • Agendaless Consulting
  • Ahmed Bouchefra
  • Al-Ahmadgaid Asaad
  • Alec Munro
  • Alex Grönholm
  • Alex Morozov
  • Alexander Limi
  • Alexandre Conrad
  • Alexandre Vassalotti
  • Alexey Evseev
  • Allison Kaptur
  • Amjith Ramanujam
  • AmvTek
  • Anarcat
  • Anatoly Techtonik
  • Andre Roberge
  • Andrea Grandi
  • Andrew Dalke
  • Andriy Kornatskyy
  • Andy Dustman
  • Andy R. Terrel
  • Anna Martelli Ravenscroft
  • Anthony Baxter
  • Anton Belyaev
  • Anton Bobrov
  • Antonio Cuni
  • Anwesha Das
  • Ari Lamstein
  • Armin Ronacher
  • Artem Golubin
  • Artem Rys
  • Ashish Vidyarthi
  • Astro Code School
  • Automating OSINT
  • Awesome Python Applications
  • Baiju Muthukadan
  • Bajusz Tamás
  • BeDjango
  • Ben Bass
  • Ben Cook
  • Ben Rousch
  • Benjamin Peterson
  • Benji York
  • Bertrand Mathieu
  • Bhavin Gandhi
  • Bhishan Bhandari
  • BioPython News
  • Bit of Cheese
  • Bojan Mihelac
  • Brandon Rhodes
  • BreadcrumbsCollector
  • Brendan Scott
  • Brett Cannon
  • Brian Okken
  • Bruno Oliveira
  • Bruno Ponne / Coding The Past
  • Bruno Rocha
  • Caktus Consulting Group
  • Calvin Cheng
  • Calvin Spealman
  • Carl Chenet
  • Carl Düvel
  • Carl Trachte
  • Carlos Eduardo de Paula
  • Casey Duncan
  • Catherine Devlin
  • Ching-Hwa Yu
  • Chris Hager
  • Chris Miles
  • Chris Mitchell
  • Chris Moffitt
  • Chris Rose
  • Chris Warrick
  • Christian Heimes
  • Christian Ledermann
  • Christian Scholz
  • Christoph Schiessl
  • Christoph Zwerschke
  • CodeGrades
  • CodeSnipers
  • CodersLegacy
  • Coding Diet
  • Corey Gallon
  • Corey Goldberg
  • Cormoran Project
  • Cross-Platform Command Line Tools
  • CubicWeb
  • Curtis Miller
  • DSPIllustrations.com
  • DaPythonista
  • Daily Tech Video (Python)
  • Dallas Fort Worth Pythoneers
  • Dan Crosta
  • Dan Stromberg
  • Dan Yeaw
  • Daniel Bader
  • Daniel Nouri
  • Daniel Roy Greenfeld
  • Data Community DC
  • Data School
  • DataWars.io
  • Dave Beazley
  • David Amos
  • David Caron
  • David Goodger
  • David Lindelof
  • David MacIver
  • David Malcolm
  • David Szotten
  • Davide Moro
  • Davy Mitchell
  • Davy Wybiral
  • Declassed Art
  • Denis Kurov
  • Django Weblog
  • Djangostars
  • Doing Math with Python
  • Doug Hellmann
  • Dougal Matthews
  • Duncan McGreggor
  • Ed Crewe
  • Edward K. Ream
  • Eli Bendersky
  • Eniram Ltd.
  • Eray Özkural (examachine)
  • Erik Marsja
  • Etienne Desautels
  • EuroPython
  • EuroPython Society
  • Evennia
  • Everyday Superpowers
  • Fabio Zadrozny
  • Filip Wasilewski
  • Filipe Saraiva
  • First Institute of Reliable Software
  • Flavio Coelho
  • Flavio Percoco
  • Floris Bruynooghe
  • Frank Wierzbicki
  • François Dion
  • François Marier
  • Frederik Rietdijk
  • From Python Import Podcast
  • Full Stack Python
  • Gaël Varoquaux
  • Georges Dubus
  • Ghaandee on IT
  • Giampaolo Rodola
  • Giulio Fidente
  • Glenn Franxman
  • Glyph Lefkowitz
  • Go Deh
  • Gocept Weblog
  • Godson Gera
  • Graeme Cross
  • Graham Dumpleton
  • Graham Wheeler
  • Grant Baillie
  • Grant Rettke
  • Greg Taylor
  • Grig Gheorghiu
  • Grzegorz Śliwiński
  • Guido van Rossum
  • Gustavo Narea
  • Gustavo Niemeyer
  • Gökhan Sever
  • Hernan Grecco
  • Hilary Mason
  • Holger Krekel
  • Holger Peters
  • HoloViz
  • Hugo van Kemenade
  • Humberto Rocha
  • Hynek Schlawack
  • Ian Ozsvald
  • Ilian Iliev
  • Import Python
  • Inspired Python
  • Ionel Cristian Maries
  • IronPython-URLs
  • IslandT
  • Israel Fruchter
  • Itamar Turner Trauring
  • Ivan Velichko
  • J. Pablo Fernández
  • Jack Diederich
  • Jacob Perkins
  • Jahongir Rahmonov
  • Jaime Buelta
  • Jamal Moir
  • James Bennett
  • Janusworx
  • Jarrod Millman
  • Jean-Paul Calderone
  • Jeff Bisbee
  • Jeff Bradberry
  • Jeff Hinrichs
  • Jeff Shell
  • Jeremy Epstein
  • Jeremy Hylton
  • Jim Fulton
  • Joe Abbate
  • Joe Pitz
  • Johan Dahlin
  • John Burns
  • John Cook
  • John Jacobsen
  • John Ludhi/nbshare.io
  • Jon Parise
  • Jonathan Ellis
  • Jonathan Harrington
  • Jonathan Hartley
  • Jonathan Street
  • Jorgen Schäfer
  • Juan Manuel Contreras
  • Julien Danjou
  • Julien Tayon
  • Juri Pakaste
  • Just a little Python
  • Justin Mayer
  • Kai Lautaportti
  • Karim Elghamrawy
  • Kay Hayen
  • Kay Schluehr
  • Kelly Yancey
  • Kodnito
  • Kogan Dev
  • Konrad Delong
  • Koodaamo
  • Kristján Valur Jónsson
  • Kriti Godey
  • Kulbir Saini
  • Kumar McMillan
  • Kumar Vipin Yadav
  • Kushal Das
  • Károly Nagy
  • LAAC Technology
  • Laurent Szyster
  • Leigh Honeywell
  • Lennart Regebro
  • Leonhard Vogt
  • Lintel Technologies
  • Linux Stans
  • ListenData
  • Logilab
  • Low Kian Seong
  • Luca Botti
  • Lucas Cimon
  • Ludovic Gasc
  • Ludvig Ericson
  • Luke Plant
  • Maciej Fijalkowsk
  • Made With Mu
  • Mahmoud Hashemi
  • Malthe Borch
  • Marc Richter
  • Marc-André Lemburg
  • Marcos Dione
  • Mariatta
  • Marius Gedminas
  • Mark Dufour
  • Mark McLoughlin
  • Mark McMahon
  • Martijn Pieters
  • Martin Fitzpatrick
  • Mats Kindahl
  • Matt Layman
  • Matthew Rocklin
  • Matthew Rollings
  • Matthew Wilson
  • Matthew Wright
  • Mattias Brändström
  • Mauveweb
  • Michael Becker
  • Michael Droettboom
  • Michael Foord
  • Michael Nelson
  • Michal Kwiatkowski
  • Michał Bultrowicz
  • Michele Simionato
  • Michy Alice
  • Mike C. Fletcher
  • Mike Driscoll
  • Mike Müller
  • Mikhail Korobov
  • Mikko Ohtamaa
  • Mirek Długosz
  • Mitchell Garnaat
  • Mitya Sirenef
  • Montreal Python User Group
  • Moshe Zadka
  • Moya Project
  • Mozilla Web Development
  • Muharem Hrnjadovic
  • Mycli
  • Nadav Samet
  • Naomi Ceder
  • Natan Zabkar
  • Ned Batchelder
  • Neil Schemenauer
  • Nick Coghlan
  • Nick Craig-Wood
  • Nick Efford
  • Nick Janetakis
  • Nicola Iarocci
  • Nicolas Dumazet
  • Nicolas Paris
  • Nigel Babu
  • Nikola
  • Nikolaos Diamantis
  • Not Invented Here
  • Nsukami Patrick
  • Obey the Testing Goat
  • Ofosos
  • Omaha Python Users Group
  • Ondřej Čertík
  • Paolo Melchiorre
  • Pathwright
  • Patrice Neff
  • Patrick Kennedy
  • Paul Everitt
  • Paul Harrison
  • Paul Redman
  • Paweł Fertyk
  • Pedro Lima
  • Peter Bengtsson
  • Peter Eisentraut
  • Peter Fankhänel
  • Peter Harkins
  • Peter Hoffmann
  • Phil Hassey
  • Philip Jenvey
  • Philipp von Weitershausen
  • Philippe Normand
  • Phillip J. Eby
  • Podcast.__init__
  • Polyglot.Ninja()
  • Possbility and Probability
  • Pradeep Gowda
  • Pranav Pandey
  • Praveen Gollakota
  • Programiz
  • Programming Ideas With Jake
  • Przemysław Kołodziejczyk
  • PyATL Bytecode
  • PyBites
  • PyCharm
  • PyCoder’s Weekly
  • PyCon
  • PyPodcats
  • PyPy
  • PyTennessee
  • Python 4 Kids
  • Python 411 Podcast
  • Python Advocacy
  • Python Anywhere
  • Python Bytes
  • Python Celery - Weekly Celery Tutorials and How-tos
  • Python Circle
  • Python Data
  • Python Diary
  • Python Docs Editorial Board
  • Python Does What?!
  • Python Engineering at Microsoft
  • Python GUIs
  • Python Insider
  • Python Morsels
  • Python People
  • Python Piedmont Triad User Group
  • Python Pool
  • Python Software Foundation
  • Python Sweetness
  • Python User Groups
  • Python for Beginners
  • Python on Karan
  • Python with Myo
  • Python(x,y) News
  • PythonClub - A Brazilian collaborative blog about Python
  • PythonDebugging.com
  • Pythonicity
  • Pythonology
  • Python⇒Speed
  • Péter Szabó
  • Péter Zsoldos
  • Quansight Labs Blog
  • R David Murray
  • RMOTR
  • Ralph Bean
  • Ram Rachum
  • Randell Benavidez
  • Randle Taylor
  • Randy Zwitch
  • Raymond Hettinger
  • Read the Docs
  • Real Python
  • Red Hat Developers
  • Rene Dudfield
  • Reuven Lerner
  • Richard Tew
  • Richard Wall
  • Rickard Lindberg
  • Rishi Maker
  • Rob Galanakis
  • Robert Collins
  • Robert Zaremba
  • Robin Parmar
  • Robin Wilson
  • Rodrigo Araúj
  • Rodrigo Girão Serrão
  • RoseHosting Blog
  • Ruslan Spivak
  • Ryan Cox
  • S. Lott
  • S. R. Krishnan
  • SDJournal
  • SPE Weblog
  • STX Next
  • Salim Fadhley
  • Sandipan Dey
  • Sandro Tosi
  • Sean McGrath
  • Sebastian Pölsterl
  • Sebastian Witowski
  • Selena Deckelmann
  • Senthil Kumaran
  • Seth Michael Larson
  • Shannon -jj Behrens
  • ShiningPanda
  • Simeon Franklin
  • Simeon Visser
  • Simon
  • Simon Brunning
  • Simon Wittber
  • Simple is Better Than Complex
  • SoftFormance
  • Speed Matters
  • Spike ekipS
  • Spyder IDE
  • Stack Abuse
  • Stanislas Morbieu
  • Starzel.de
  • Stefan Behnel
  • Stefan Scherfke
  • Stefanie Molin
  • Stein Magnus Jodal
  • Stephen Ferg
  • Steve Holden
  • Steven Klass
  • Stuart Gordon Reid
  • Stéphane Wirtel
  • Sumana Harihareswara - Cogito, Ergo Sumana
  • Suresh Dasari/Tutlane.com
  • Swisscom ICT
  • Talk Python Blog
  • Talk Python to Me
  • Taylor Edmiston
  • TechBeamers Python
  • Techiediaries - Django
  • Terri Oda
  • Terry Jones
  • Test and Code
  • TestDriven.io
  • The Data Scientist
  • The Digital Cat
  • The Lunar Cowboy
  • The No Title® Tech Blog
  • The Occasional Occurrence
  • The Open Sourcerer
  • The Parcon Blog
  • The Python Coding Blog
  • The Python Coding Stack
  • The Python Papers
  • The Python Show
  • The Three of Wands
  • Thibauld Nion
  • ThisHosting.Rocks
  • Thomas Guest
  • Thomas Vander Stichele
  • Tibo Beijen
  • Tim Arnold / reachtim
  • Tim Gilbert
  • Tim Knapp
  • Tim Lesher
  • Tobias Ivarsson
  • Tom Christie
  • Tomasz Ducin
  • Tomaž Muraus
  • Tomer Filiba
  • Tony Breyal
  • Toshio Kuratomi
  • Travis Oliphant
  • Trey Hunner
  • Tryton News
  • Turnkey Linux
  • Twisted Matrix Labs
  • TypeThePipe
  • V.S. Babu
  • Varun Nischal
  • Vasudev Ram
  • Vinay Sajip
  • Vinay Sajip (Logging)
  • Vinayak Mehta
  • Virgil Dupras
  • Vladimir Perić
  • Wayne Witzel
  • Weekly Python Chat
  • Weekly Python StackOverflow Report
  • Wes Mason
  • Wesley Chun
  • Will Kahn-Greene
  • Will McGugan
  • Will Pierce
  • William Minchin
  • William Reade
  • Wing Tips
  • Wingware
  • Wyatt Baldwin
  • Yaniv Aknin
  • Yann Larrivée
  • Yuval Greenfield
  • Zaki Akhmad
  • Zato Blog
  • Zero to Mastery
  • Zero-with-Dot (Oleg Żero)
  • ZeroDB
  • bottlepy-dev
  • codeboje
  • death and gravity
  • eGenix.com
  • hypothesis.works articles
  • kdev-python
  • meejah.ca
  • nl-project
  • pgcli
  • py.CheckIO
  • pygame
  • pythonwise
  • qutebrowser development blog
  • saaj/recollection
  • scikit-learn
  • testmon
  • tryexceptpass
  • Éric Araujo
  • Łukasz Langa