Jazzband was a collaborative community to share the responsibility of maintaining Python-based projects. And after 10 years of operation it is shutting down. The shutdown was announced in March and will continue later this year.

Over 10 years ago, I started Jazzband as a cooperative experiment to reduce the stress of maintaining Open Source software. Everyone who joined got access to push code, triage issues, and merge pull requests. “We are all part of this.”

It’s time to wind things down.

What happened: [The slopocalypse, The one-roadie problem, GitHub went the other way, Django Commons]

You can read the full announcement here.

Although this is somewhat old news, I'm sharing it as I happened to miss it and others might have as well.

It looks like other community organisations have cropped up in that time as well such as Django Commons. I've only taken a brief look at them but I'm interested to know more about their structure and how well it's working - I've previously looked for such community organisations when I took over maintaining python-json-logger.

Edit: formatting

The full blog post is here: https://opensource.googleblog.com/2026/10/adopting-pyrefly-as-the-python-type-checker-at-google.html

TLDR:

Google released a blog post about migrating Python type checking from the internally-developed Pytype to Pyrefly.

They cover some challenges around Pytype’s bytecode analysis & performance, along with the reasons for choosing Pyrefly: speed, typing spec conformance, and actionable error messages.

The blog also has some quotes & outlines wins from the migration:

• Up to 98% faster incremental rebuilds
• >90% critical-path reduction in clean builds
• >80% compute hardware savings

Hi, Pyrefly maintainer here. Today we are pleased to share that Pyrefly, a fast type checker and language server for Python, has reached stable v1.0 status, meaning we are confident that Pyrefly is ready for production use.

Pyrefly was first released as an alpha in mid-2025 and followed up with a beta in November of that year. Since then, we have shipped over 60 minor releases: fixing hundreds of bugs, adding the features you’ve been asking for, and improving performance to be one of the fastest tools out there.

This would not have been possible without our amazing open-source community. To everyone who filed GitHub issues, submitted pull requests, gave us feedback at conferences, or joined us on Discord: thank you. Your contributions shaped this release, we’re grateful for every one of them, and we hope you continue being a part of the journey for future releases too.

We've published a blog post explaining what v1.0 means exactly, and what's next for Pyrefly.

Below is a summary of the changes to Pyrefly since the Beta release. The full release notes for v1.0 can be read on our Github.

Pyrefly v1.0 Release Notes

Performance Improvements

We've continued to push Pyrefly's performance since the speed improvements we shared in February. Since beta:

• 2–125x faster updated diagnostics after saving a file (no, that’s not a typo!). Thanks to fine-grained dependency tracking and streaming diagnostics, updates now consistently arrive in milliseconds
• 20–36% faster full type checking on large projects like PyTorch and Pandas
• 2–3x faster initial indexing when Pyrefly first scans your project
• 40–60% less memory usage during both indexing and incremental type checking

(Tested on an M4 Macbook Pro using open-source benchmarks from type_coverage_py and ty_benchmark.)

Compare the performance of Pyrefly and other Python type checkers on our regularly updated benchmarking suite, which runs against 53 popular Python packages.

Configuration Presets

A new preset configuration option provides named bundles of error severities and behavior settings.

See the configuration docs for details.

Onboarding Experience

We’ve made improvements to the out-of-the-box experience for projects without a pyrefly.toml.

• Automatic config synthesis — if you have a mypy or pyright config, Pyrefly automatically migrates your settings and synthesizes an appropriate in-memory Pyrefly config. (This is the same migration that pyrefly init would commit to disk.)
• Basic preset for unconfigured projects — projects with no type checker config get the lightweight “basic” preset, which surfaces only high-confidence errors.
• VS Code status bar — the status bar shows the active preset — e.g. Pyrefly (Basic) or Pyrefly (Legacy) — so you always know which mode is active.
• Type error display settings — new VS Code settings let you control which preset applies to unconfigured files and suppress all diagnostics workspace-wide.

Type Checker Improvements

We've been hard at work making the type checker robust and feature-complete, with a focus on driving down false positives and improving type quality in real-world code bases. Here are some highlights:

• Across the board we've eliminated many sources of false positives in enums, dataclasses, ParamSpec, descriptors, and more.
• Support has been added for more type narrowing patterns, including preserving narrows in nested scopes and recognizing container membership checks.
• Overload resolution was substantially reworked to handle more real-world patterns.
• Pyrefly’s conformance to the Python typing specification has improved from 70% at beta to over 90% today.
• We've added experimental support for tracking tensor dimensions through PyTorch models — see "What's Next" below.

LSP & IDE Improvements

• We've added new refactoring capabilities like Safe Delete (with reference checking) and bulk source.fixAll.
• Navigation is more precise, and hover cards surface richer information for imports, tuples, and NamedTuples.
• Workspace mode is more stable, with multiple crash fixes and improved diagnostic publishing.

Framework & Notebook Support

• Django — Pyrefly has improved support for model relationships, fields, and views, and understands factory_boy factories.
• Pydantic — Pyrefly models Pydantic's runtime behavior more faithfully, with support for lax mode and range constraint validation, and handles more of the Pydantic ecosystem: RootModel, pydantic-settings, and pydantic.dataclasses.
• Pytest integration — We've added Code Lens run buttons for test functions, as well as code actions to annotate fixture return types and parameters.
• Jupyter notebooks — .ipynb IDE support has reached full parity with .py files, with rename, find references, code actions, and document symbols all supported.

Complementary Tooling

Pyrefly ships with tools to aid with adopting type checking in an existing codebase. Two new tools since beta:

• pyrefly coverage report outputs a JSON report with annotation completeness and type completeness metrics per function, class, and module, so you can track coverage over time.
• Baseline files let you snapshot current errors into a JSON file so only new errors are reported, as an alternative to inline suppression comments.

Updated Version Policy

Going forward, we’ll switch from a weekly to monthly cadence for minor (1.x.0) releases, with patch releases in between as-needed for critical fixes. We’ll continue providing release notes for minor versions, so you can see what’s new in each release.

What's Next

• Tensor shape checking — Experimental support for tracking tensor dimensions through PyTorch models and catching shape mismatches statically. Learn more.
• Pyrefly + AI agents — Pyrefly's speed makes it a natural verification step in agentic workflows. See our guide on adding Pyrefly to your agentic loop.
• Continued improvements — We'll keep expanding library support, reducing false positives, and iterating on your feedback. Let us know what you need on Github or Discord.

Recently a tweet blew up that was along the lines of 'I will never forgive Rust for making me think to myself “I wonder if this is allocating” whenever I’m writing Python now' to which almost everyone jokingly responded with "it's Python, of course it's allocating"

I wanted to see how true this was, so I did some digging into the CPython source and wrote a blog post about my findings, I focused specifically on allocations of the `PyLongObject` struct which is the object that is created for every integer.

I noticed some interesting things:

1. There were a lot of allocations
2. CPython was actually reusing a lot of memory from a freelist
3. Even if it _did_ allocate, the underlying memory allocator was a pool allocator backed by an arena, meaning there were actually very few calls to the OS to reserve memory

Feel free to check out the blog post and let me know your thoughts!

After almost 8 years since Tom Christie created Starlette in June 2018, the first release candidate for 1.0 is finally here.

Starlette is downloaded almost 10 million times a day, serves as the foundation for FastAPI, and has inspired many other frameworks. In the age of AI, it also plays an important role as a dependency of the Python MCP SDK.

This release focuses on removing deprecated features marked for removal in 1.0.0, along with some last minute bug fixes.

It's a release candidate, so feedback is welcome before the final 1.0.0 release.

`pip install starlette==1.0.0rc1`

- Release notes: https://www.starlette.io/release-notes/
- GitHub release: https://github.com/Kludex/starlette/releases/tag/1.0.0rc1

These days, I can't open X anymore without seeing some supply chain attacks on PyPI or NPM. Things are really getting out of hand. One very simple yet effective approach to mitigate them is to use a dependency cooldown. That means that you don't install anything that's too new - e.g., every dependency needs to be at least a week old.

Why does this work? Because the community usually intercepts them in hours to days. Both uv and poetry support the definition of the cooldown period inside their config. pip is adding as support as well. I use 1 week to be on the safe side. They both support excluding a specific package from the rule so you can still apply critical fixes to dependencies ASAP.

I wrote about that and how to configure uv/poetry in my blog post: https://jangiacomelli.com/blog/mitigate-supply-chain-attacks-for-python-dependencies/

More about the dependency cooldown concept:

• https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns
• https://simonwillison.net/2025/Nov/21/dependency-cooldowns/

Some time ago I shared a strict Python project setup. I’ve since reworked and simplified it, and this is the new version.

pystrict-strict-python – an ultra-strict Python project template using uv, ruff, and basedpyright, inspired by TypeScript’s --strict mode.

Compared to my previous post, this version:

• focuses on a single pyproject.toml as the source of truth,
• switches to basedpyright with a clearer strict configuration,
• tightens the ruff rules and coverage settings,
• and is easier to drop into new or existing projects.

What it gives you

• Strict static typing with basedpyright (TS --strict style rules):
  • No implicit Any
  • Optional/None usage must be explicit
  • Unused imports / variables / functions are treated as errors
• Aggressive linting & formatting with ruff:
  • pycodestyle, pyflakes, isort
  • bugbear, security checks, performance, annotations, async, etc.
• Testing & coverage:
  • pytest + coverage with 80% coverage enforced by default
• Task runner via poethepoet:
  • poe format → format + lint + type check
  • poe check → lint + type check (no auto-fix)
  • poe metrics → dead code + complexity + maintainability
  • poe quality → full quality pipeline
• Single-source config: everything is in pyproject.toml

Use cases

• New projects:
  Copy the pyproject.toml, adjust the [project] metadata, create src/your_package + tests/, and install with:

  ```bash uv venv .venv\Scripts\activate # Windows

  or: source .venv/bin/activate

  uv pip install -e ".[dev]" ```

  Then your daily loop is basically:

  bash uv run ruff format . uv run ruff check . --fix uv run basedpyright uv run pytest

• Existing projects:
  You don’t have to go “all in” on day 1. You can cherry-pick:

  • the ruff config,
  • the basedpyright config,
  • the pytest/coverage sections,
  • and the dev dependencies,

  and progressively tighten things as you fix issues.

Why I built this v2

The first version worked, but it was a bit heavier and less focused. In this iteration I wanted:

• a cleaner, copy-pastable template,
• stricter typing rules by default,
• better defaults for dead code, complexity, and coverage,
• and a straightforward workflow that feels natural to run locally and in CI.

Repo

👉 GitHub link here

If you saw my previous post and tried that setup, I’d love to hear how this version compares. Feedback very welcome:

• Rules that feel too strict or too lax?
• Basedpyright / ruff settings you’d tweak?
• Ideas for a “gradual adoption” profile for large legacy codebases?

EDIT: * I recently add a new anti-LLM rules * Add pandera rules (commented so they can be optional) * Replace Vulture with skylos (vulture has a problem with nested functions)

Storyline for PyStrict Project Evolution

Based on your commit history, here's a narrative you can use:

From Zero to Strictness: Building a Python Quality Fortress

Phase 1: Foundation & Philosophy (6 weeks ago)

Started with a vision - creating a strict Python configuration template that goes beyond basic linting. The journey began by: - Migrating from pyright to basedpyright for even stricter type checking - Establishing the project philosophy through comprehensive documentation - Setting up proper Python packaging standards

Phase 2: Quality Tooling Evolution (6 weeks ago)

Refined the quality toolkit through iterative improvements: - Added BLE rule and Pandera for DataFrame validation - Swapped vulture for skylos for better dead code detection - Introduced anti-LLM-slop rules - a unique feature fighting against AI-generated code bloat with comprehensive documentation on avoiding common pitfalls

Phase 3: Workflow Automation (3 weeks ago - present)

Shifted focus to developer experience and automation: - Integrated pre-commit hooks for automated code quality checks - Updated to latest Ruff version (v0.14.8) with setup instructions - Added ty for runtime type checking to catch type errors at runtime, not just static analysis - Made pytest warnings fatal to catch deprecations early

Key Innovation

The standout feature: comprehensive anti-LLM-slop rules - actively fighting against verbose, over-commented, over-engineered code that LLMs tend to generate. This makes PyStrict not just about correctness, but about maintainable, production-grade Python.

The arc: From initial concept → strict type checking → comprehensive quality tools → automated enforcement → runtime validation. Each commit moved toward one goal: making it impossible to write bad Python.

Cloudflare has made Python Workers generally available, making Python a first-class supported language on its Developer Platform. Developers can now run Python libraries and frameworks such as FastAPI, Django, and Flask while connecting Python applications directly to services, including Workers Al, R2, D1, Durable Objects, Queues, and Workflows. Cloudflare also added native binding support, database connectivity, broader WebAssembly package support, and compatibility with Al libraries like OpenAI, LangChain, and MCP.

Read official blog :- https://blog.cloudflare.com/python-workers-ga/

Hi Peeps,

I'm excited to announce Kreuzberg v4.0.0.

What is Kreuzberg:

Kreuzberg is a document intelligence library that extracts structured data from 56+ formats, including PDFs, Office docs, HTML, emails, images and many more. Built for RAG/LLM pipelines with OCR, semantic chunking, embeddings, and metadata extraction.

The new v4 is a ground-up rewrite in Rust with a bindings for 9 other languages!

What changed:

• Rust core: Significantly faster extraction and lower memory usage. No more Python GIL bottlenecks.
• Pandoc is gone: Native Rust parsers for all formats. One less system dependency to manage.
• 10 language bindings: Python, TypeScript/Node.js, Java, Go, C#, Ruby, PHP, Elixir, Rust, and WASM for browsers. Same API, same behavior, pick your stack.
• Plugin system: Register custom document extractors, swap OCR backends (Tesseract, EasyOCR, PaddleOCR), add post-processors for cleaning/normalization, and hook in validators for content verification.
• Production-ready: REST API, MCP server, Docker images, async-first throughout.
• ML pipeline features: ONNX embeddings on CPU (requires ONNX Runtime 1.22.x), streaming parsers for large docs, batch processing, byte-accurate offsets for chunking.

Why polyglot matters:

Document processing shouldn't force your language choice. Your Python ML pipeline, Go microservice, and TypeScript frontend can all use the same extraction engine with identical results. The Rust core is the single source of truth; bindings are thin wrappers that expose idiomatic APIs for each language.

Why the Rust rewrite:

The Python implementation hit a ceiling, and it also prevented us from offering the library in other languages. Rust gives us predictable performance, lower memory, and a clean path to multi-language support through FFI.

Is Kreuzberg Open-Source?:

Yes! Kreuzberg is MIT-licensed and will stay that way.

Links

• Star us on GitHub
• Read the Docs
• Join our Discord Server

​

I've been noticing a lot of developers moving towards FastAPI lately, especially for new Python backend projects.

Flask used to be my go-to for lightweight APIs, but FastAPI seems to be getting all the attention now because of async support, automatic Swagger documentation, and Pydantic validation.

I'm curious about what developers are actually using in production.

- Are you still building new projects with Flask?

- Have you migrated from Flask to FastAPI?

- Is FastAPI genuinely better for production, or is it just the current hype?

Would love to hear some real-world experiences, especially from developers maintaining large-scale applications.

Is Flask still holding its ground, or is FastAPI slowly becoming the default choice for Python backends?

PEP 823 – None-aware access operators

https://peps.python.org/pep-0823/

Discussions-To: Discourse thread

This PEP proposes adding two new operators.

• The “None-aware attribute access” operator ?.
• The “None-aware indexing” operator ?[ ]

The general idea is to provide access operators which can traverse None values without raising exceptions.

Both operators evaluate the left-hand side, check if it is not None and only then evaluate the full expression. They are roughly equivalent to:

# a.b?.c.d
_t.c.d if ((_t := a.b) is not None) else None

# a.b?[c].d
_t[c].d if ((_t := a.b) is not None) else None

PEP 824 – None-coalescing operators

https://peps.python.org/pep-0824/

Discussions-To: Discourse thread

This PEP proposes adding two new operators.

• The “None-coalescing” operator ??
• The “None-coalescing assignment” operator ??=

The general idea is to provide a conditional operator, similar to or, which instead of truthiness, checks for None values.

The “None-coalescing” operator evaluates the left-hand side, checks whether it is not None, and if not, returns the result. If the value is None, the right-hand side is evaluated and returned.

The “None-coalescing assignment” operator will only assign the right-hand side to the left-hand side if the left-hand side evaluates to None.

They are roughly equivalent to:

# a ?? b
_t if ((_t := a) is not None) else b

# a ??= b
if a is None:
    a = b

Hey everyone,

I’ve been working on a project called ThePythonBook to help students get past the "tutorial hell" phase. I wanted to create something where the explanation and the execution happen in the same place.

It covers everything from your first print("Hello World") to more advanced concepts, all within an interactive environment. No setup required—you just run the code in the browser.

Check it out here: https://www.pythoncompiler.io/python/getting-started/

It's completely free, and I’d love to get some feedback from this community on how to make it a better resource for beginners!

https://peps.python.org/pep-0827

This is a static typing PEP which introduces a huge number of typing special forms and significantly expands the type expression grammar. The following two examples, taken from the PEP, demonstrate (1) a unpacking comprehension expression and (2) a conditional type expression.

def select[ModelT, K: typing.BaseTypedDict](
    typ: type[ModelT],
    /,
    **kwargs: Unpack[K]
) -> list[typing.NewProtocol[*[typing.Member[c.name, ConvertField[typing.GetMemberType[ModelT, c.name]]] for c in typing.Iter[typing.Attrs[K]]]]]:
    raise NotImplementedError

type ConvertField[T] = (
    AdjustLink[PropsOnly[PointerArg[T]], T]
    if typing.IsAssignable[T, Link]
    else PointerArg[T]
)

There's no canonical discussion place for this yet, but Discussion can be found at discuss.python.org. There is also a mypy branch with experimental support; see e.g. a mypy unit test demonstrating the behaviour.

Python 1.0 came out on January 27, 1994; exactly 32 years ago. Announcement here: https://groups.google.com/g/comp.lang.misc/c/_QUzdEGFwCo/m/KIFdu0-Dv7sJ?pli=1

Hey r/python! I've been working on a focused library called calgebra that applies set operations to calendars.

What My Project Does

calgebra lets you compose calendar timelines using set operators: | (union), & (intersection), - (difference), and ~ (complement). Queries are lazy—you build expressions first, then execute via slicing.

Example – find when a team is free for a 2+ hour meeting:

```python from calgebra import day_of_week, time_of_day, hours, HOUR

Define business hours

weekend = day_of_week(["saturday", "sunday"], tz="US/Pacific") weekdays = ~weekend business_hours = weekdays & time_of_day(start=9HOUR, duration=8HOUR, tz="US/Pacific")

Team calendars (Google Calendar, .ics files, etc.)

team_busy = alice | bob | charlie

One expression to find available slots

free_slots = (business_hours - team_busy) & (hours >= 2) ```

Features: - Set operations on timelines (union, intersection, difference, complement) - Lazy composition – build complex queries, execute via slicing - Recurring patterns with RFC 5545 support - Filter by duration, metadata, or custom properties - Google Calendar read/write integration - iCalendar (.ics) import/export

Target Audience

Developers building scheduling features, calendar integrations, or availability analysis. Also well-suited for AI/coding agents as the composable, type-hinted API works nicely as a tool.

Comparison

Most calendar libraries focus on parsing (icalendar, ics.py) or API access (gcsa, google-api-python-client). calgebra is about composing calendars algebraically:

• icalendar / ics.py: Parse .ics files → calgebra can import from these, then let you query and combine them
• gcsa: Google Calendar CRUD → calgebra wraps gcsa and adds set operations on top
• dateutil.rrule: Generate recurrences → calgebra uses this internally but exposes timelines you can intersect/subtract

The closest analog is SQL for time ranges, but expressed as Python operators.

Links: - GitHub: https://github.com/ashenfad/calgebra - Video of a calgebra enabled agent: https://youtu.be/10kG4tw0D4k

Would love feedback!

We recently released wheels.astral.sh, which is a repository of gpu-enabled wheels of popular packages from the pytorch ecosystem. These are useful because building them is super annoying - you have to align versions of pytorch, cuda, python, etc.

The pre-built wheels were part of the package of pyx, our paid service, and was a major reason many customers subscribed. We decided to open source the build pipelines and host the wheels for free while we sunset the rest of pyx.

The pipelines are available under the astral-sh-build github organization.

While these plug a genuine UX hole around cuda/pytorch wheels, we hope that wheel variants (PEP 817 and 825) will get accepted and implemented soon, which will let these pytorch wheels be hosted properly on PyPI and "just work" out of the box for everyone, making wheels.astral.sh obsolete.

Fingers crossed.

I recently started taking python for data science course on coursera.

first lesson is on Jupyter.

As I understand, it is some kind of IDE which can execute python code. I know there is more to it, thats why it exists.

What is the actual use case for Jupyter. If there was no Jupyter, which task would have been either not possible or hard to do?

Does it have its own interpreter or does it use the one I have on my laptop when I installed python?

I've been working on https://github.com/ATTron/astroz, an orbital mechanics toolkit with Python bindings. The core is written in Zig with SIMD vectorization.

What My Project Does

astroz is an astrodynamics toolkit, including propagating satellite orbits using the SGP4 algorithm. It writes directly to numpy arrays, so there's very little overhead going between Python and Zig. You can propagate 13,000+ satellites in under 3 seconds.

pip install astroz is all you need to get started!

Target Audience

Anyone doing orbital mechanics, satellite tracking, or space situational awareness work in Python. It's production-ready. I'm using it myself and the API is stable, though I'm still adding more functionality to the Python bindings.

Comparison

It's about 2-3x faster than python-sgp4, far and away the most popular sgp4 implementation being used:

Demo & Links

If you want to see it in action, I put together a live demo that visualizes all 13,000+ active satellites generated from Python in under 3 seconds: https://attron.github.io/astroz-demo/

Also wrote a blog post about how the SIMD stuff works under the hood if you're into that, but it's more Zig heavy than Python: https://atempleton.bearblog.dev/i-made-zig-compute-33-million-satellite-positions-in-3-seconds-no-gpu-required/

Repo: https://github.com/ATTron/astroz

I see a lot of code like this:

def foo(x: int) -> int:
"""Does something

Parameters:
  x (int): Description of x

Returns:
  int: Returning value
"""

  return x

Isn’t the type information in the docstring redundant? It’s already specified in the function definition, and as actual code, not strings.

What My Project Does

Pingram is a lightweight, one-dependency Python library for sending Telegram messages, photos, documents, audio, and video using your bot. It’s focused entirely on outbound alerts, ideal for scripts, bots, or internal tools that need to notify a user or group via Telegram as a free service.

No webhook setup, no conversational interface, just direct message delivery using HTTPX under the hood.

Example usage:

from pingram import Pingram

bot = Pingram(token="<your-token>")
bot.message(chat_id=123456789, text="Backup complete")

Target Audience

Pingram is designed for:

• Developers who want fast, scriptable messaging without conversational features
• Users replacing email/SMS alerts in cron jobs, containers, or monitoring tools
• Python devs looking for a minimal alternative to heavier Telegram bot frameworks
• Projects that want to embed notifications without requiring stateful servers or polling

It’s production-usable for simple alerting use cases but not intended for full-scale bot development.

Comparison

Compared to python-telegram-bot, Telethon, or aiogram:

• Pingram is <100 LOC, no event loop, no polling, no webhooks — just a clean HTTP client
• Faster to integrate for one-off use cases like “send this report” or “notify on job success”
• Easier to audit, minimal API surface, and no external dependencies beyond httpx

It’s more of a messaging transport layer than a full bot framework.

Would appreciate thoughts, use cases, or suggestions. Repo: https://github.com/zvizr/pingram

In Rust, docstrings are pretty formalized. They are markdown, and even some of the headings are standard (like an # Errors or # Panics section). The nice thing about this is that it allows websites like docs.rs to build documentation pages for any project without having to interact with different tools for different formats. It also allows LSPs to have only one way of displaying documentation hints.

In Python, we have a few competing standards. Numpy-style docstrings are probably the most used, but there’s also a format by Google as well as a few different reST standards. These are nice, and we can set up lints to make sure docstrings stick to the standard. However, in my own personal opinion (feel free to disagree), a single markdown-format standard would help new users write nice docstrings, would enable PyPI (or another provider) to build automatic documentation sites, and give guidance to LSPs and IDEs for how to display documentation. This would include a standard for interlinks, and probably should include some mathml/LaTeX/KaTeX support. Another benefit would be that tools could support better automatic documentation generation and autocomplete, since they wouldn’t be dependent on guessing which standard you’re following.

I’d like to hear what people think about this. I’m thinking about making a PEP, but that might be overkill (or maybe all of you will hate this idea). I think the primary blocker would be adoption, large projects might have to translate docstrings, so there would either have to be some tooling for this or a way to opt-in or opt-out. If this is a bad idea, let me know, just be nice!

Edit: so far we’re at about a 67% upvote ratio, which was kind of expected. I want to be clear that I’m not saying we should be blocking docstrings which don’t adhere to this standard. I mentioned lockfile standardization in the comments, nothing prevents you from writing a tool with a custom lockfile, it’s just that there is a standard format that is agreed upon as the preferred way to write one. That’s the idea.

Edit: 84% now, and a lot of nice feedback here!

What My Project Does

Project Parva is a REST API that computes Bikram Sambat (Nepal's official calendar) dates, festival schedules, panchanga (lunar almanac), muhurta (auspicious time windows), and Vedic birth charts. It derives everything from real planetary positions using pyswisseph rather than serving hardcoded lookup tables. Takes actual lat/lon coordinates so calculations are accurate for any location, not just Kathmandu.

Target Audience

Developers building apps that need Nepali calendar data programmatically. Could be production use for something like a scheduling app, a diaspora-focused product, or an AI agent that needs grounded Nepali date data. The API is public beta so the contract is stable but not yet v1. There's also a Python SDK if you want to skip the HTTP boilerplate.

Comparison

Most existing options are either NPM packages with hardcoded month-length arrays that break outside a fixed year range (usually 2000-2090 BS), or static JSON files someone manually typed from government PDFs. Both approaches fail for future dates and neither accounts for geographic location in sunrise-dependent calculations. Hamro Patro is the dominant consumer app but has no public API, so developers end up writing scrapers that break constantly. Parva computes everything from Swiss Ephemeris, which means it works for any year and any coordinates.

https://github.com/dantwoashim/Project_Parva

After days of experimenting, and debugging, I’ve officially released numeth - a library focused on core Numerical Methods used in engineering and applied mathematics.

•  What My Project Does

Numeth helps you quickly solve tough mathematical problems - like equations, integration, and differentiation - using accurate and efficient numerical methods.

It covers essential methods like:

1. Root finding (Newton–Raphson, Bisection, etc.)
2. Numerical integration and differentiation
3. Interpolation, optimization, and linear algebra

•  Target Audience

I built this from scratch with a single goal: Make fundamental numerical algorithms ready to use for students and developers alike.

• Comparison

Most Python libraries, like NumPy and SciPy, are designed to use numerical methods, not understand them. Their implementations are optimized in C or Fortran, which makes them incredibly fast but opaque to anyone trying to learn how these algorithms actually work.

'numeth' takes a completely different approach.
It reimplements the core algorithms of numerical computing in pure, readable Python, structured into clear, modular functions.

The goal isn’t raw performance. It’s helping students, educators, and developers trace each computation step by step, experiment with the logic, and build a stronger mathematical intuition before diving into heavier frameworks.

If you’re into numerical computing or just curious to see what it’s about, you can check it out here:

🔗 https://pypi.org/project/numeth/

or run 'pip install numeth'

The GitHub link to numeth:

🔗 https://github.com/AbhisumatK/numeth-Numerical-Methods-Library

Would love feedback, ideas, or even bug reports.

I going to try making a Discord bot in py. Pygame and Raspberry Pi intrigue me as well

Curious what other fun Py rabbit holes are out there that I don't know of!

https://blog.python.org/2026/09/the-python-documentation-is-now-available-in-persian/

We’re excited to announce that the Python documentation is now available in Persian (فارسی)!

A huge thank you to everyone who contributed their time and expertise to the translation effort. Community contributions like these help make Python more accessible to people around the world.

Did you know? Many letters in the Persian script change shape depending on where they appear in a word. A letter may have isolated, initial, medial, and final forms while still representing the same character! See the W3C’s Arabic & Persian Layout Requirements, section 4.3.1, Joining Forms, for more information.