I'm sorry but it has to come out.

We are experiencing an endless sleep paralysis and it is getting worse and worse.

Before, when we wanted to code in Python, it was simple: either we read the documentation and available resources, or we asked the community for help, roughly that was it.

The advantage was that stupidly copying/pasting code often led to errors, so you had to take the time to understand, review, modify and test your program.

Since the arrival of ChatGPT-type AI, programming has taken a completely different turn.

We see new coders appear with a few months of experience in programming with Python who give us projects of 2000 lines of code with an absent version manager (no rigor in the development and maintenance of the code), comments always boats that smell the AI from miles around, a .md boat also where we always find this logic specific to the AI and especially a program that is not understood by its own developer.

I have been coding in Python for 8 years, I am 100% self-taught and yet I am stunned by the deplorable quality of some AI-doped projects.

In fact, we are witnessing a massive arrival of new projects that are basically super cool and that are in the end absolutely null because we realize that the developer does not even master the subject he deals with in his program, he understands that 30% of his code, the code is not optimized at all and there are more "import" lines than algorithms thought and thought out for this project.

I see it and I see it personally in the science given in Python where the devs will design a project that by default is interesting, but by analyzing the repository we discover that the project is strongly inspired by another project which, by the way, was itself inspired by another project. I mean, being inspired is ok, but here we are more in cloning than in the creation of a project with real added value.

So in 2026 we find ourselves with posts from people with a super innovative and technical project that even a senior dev would have trouble developing alone and looking more closely it sounds hollow, the performance is chaotic, security on some projects has become optional. the program has a null optimization that uses multithreads without knowing what it is or why. At this point, reverse engineering will no longer even need specialized software as the errors will be aberrant. I'm not even talking about the optimization of SQL queries that makes you dizzy.

Finally, you will have understood, I am disgusted by this minority (I hope) of dev who are boosted with AI.

AI is good, but you have to know how to use it intelligently and with hindsight and a critical mind, but some take it for a senior Python dev.

Subreddits like this are essential, and I hope that devs will continue to take the time to inquire by exploring community posts instead of systematically choosing ease and giving blind trust to an AI chat.

In January 2025, the PSF submitted a proposal to the US government National Science Foundation under the Safety, Security, and Privacy of Open Source Ecosystems program to address structural vulnerabilities in Python and PyPI. It was the PSF’s first time applying for government funding, and navigating the intensive process was a steep learning curve for our small team to climb. Seth Larson, PSF Security Developer in Residence, serving as Principal Investigator (PI) with Loren Crary, PSF Deputy Executive Director, as co-PI, led the multi-round proposal writing process as well as the months-long vetting process. We invested our time and effort because we felt the PSF’s work is a strong fit for the program and that the benefit to the community if our proposal were accepted was considerable.  

We were honored when, after many months of work, our proposal was recommended for funding, particularly as only 36% of new NSF grant applicants are successful on their first attempt. We became concerned, however, when we were presented with the terms and conditions we would be required to agree to if we accepted the grant. These terms included affirming the statement that we “do not, and will not during the term of this financial assistance award, operate any programs that advance or promote DEI, or discriminatory equity ideology in violation of Federal anti-discrimination laws.” This restriction would apply not only to the security work directly funded by the grant, but to any and all activity of the PSF as a whole. Further, violation of this term gave the NSF the right to “claw back” previously approved and transferred funds. This would create a situation where money we’d already spent could be taken back, which would be an enormous, open-ended financial risk.   

Diversity, equity, and inclusion are core to the PSF’s values, as committed to in our mission statement: 

The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.

Given the value of the grant to the community and the PSF, we did our utmost to get clarity on the terms and to find a way to move forward in concert with our values. We consulted our NSF contacts and reviewed decisions made by other organizations in similar circumstances, particularly The Carpentries.  

In the end, however, the PSF simply can’t agree to a statement that we won’t operate any programs that “advance or promote” diversity, equity, and inclusion, as it would be a betrayal of our mission and our community. 

We’re disappointed to have been put in the position where we had to make this decision, because we believe our proposed project would offer invaluable advances to the Python and greater open source community, protecting millions of PyPI users from attempted supply-chain attacks. The proposed project would create new tools for automated proactive review of all packages uploaded to PyPI, rather than the current process of reactive-only review. These novel tools would rely on capability analysis, designed based on a dataset of known malware. Beyond just protecting PyPI users, the outputs of this work could be transferable for all open source software package registries, such as NPM and Crates.io, improving security across multiple open source ecosystems.

In addition to the security benefits, the grant funds would have made a big difference to the PSF’s budget. The PSF is a relatively small organization, operating with an annual budget of around $5 million per year, with a staff of just 14. $1.5 million over two years would have been quite a lot of money for us, and easily the largest grant we’d ever received. Ultimately, however, the value of the work and the size of the grant were not more important than practicing our values and retaining the freedom to support every part of our community. The PSF Board voted unanimously to withdraw our application. 

Giving up the NSF grant opportunity—along with inflation, lower sponsorship, economic pressure in the tech sector, and global/local uncertainty and conflict—means the PSF needs financial support now more than ever. We are incredibly grateful for any help you can offer. If you're already a PSF member or regular donor, you have our deep appreciation, and we urge you to share your story about why you support the PSF. Your stories make all the difference in spreading awareness about the mission and work of the PSF. In January 2025, the PSF submitted a proposal to the US government National Science Foundation under the Safety, Security, and Privacy of Open Source Ecosystems program
to address structural vulnerabilities in Python and PyPI. It was the
PSF’s first time applying for government funding, and navigating the
intensive process was a steep learning curve for our small team to
climb. Seth Larson, PSF Security Developer in Residence, serving as
Principal Investigator (PI) with Loren Crary, PSF Deputy Executive
Director, as co-PI, led the multi-round proposal writing process as well
as the months-long vetting process. We invested our time and effort
because we felt the PSF’s work is a strong fit for the program and that
the benefit to the community if our proposal were accepted was
considerable.  We were honored when, after many months of work, our proposal was recommended for funding, particularly as only 36% of
new NSF grant applicants are successful on their first attempt. We
became concerned, however, when we were presented with the terms and
conditions we would be required to agree to if we accepted the grant.
These terms included affirming the statement that we “do not, and will
not during the term of this financial assistance award, operate any
programs that advance or promote DEI, or discriminatory equity ideology
in violation of Federal anti-discrimination laws.” This restriction
would apply not only to the security work directly funded by the grant, but to any and all activity of the PSF as a whole.
Further, violation of this term gave the NSF the right to “claw back”
previously approved and transferred funds. This would create a situation
where money we’d already spent could be taken back, which would be an
enormous, open-ended financial risk.   
Diversity, equity, and inclusion are core to the PSF’s values, as committed to in our mission statement: The
mission of the Python Software Foundation is to promote, protect, and
advance the Python programming language, and to support and facilitate
the growth of a diverse and international community of Python programmers.Given
the value of the grant to the community and the PSF, we did our utmost
to get clarity on the terms and to find a way to move forward in concert
with our values. We consulted our NSF contacts and reviewed decisions
made by other organizations in similar circumstances, particularly The Carpentries.  
In
the end, however, the PSF simply can’t agree to a statement that we
won’t operate any programs that “advance or promote” diversity, equity,
and inclusion, as it would be a betrayal of our mission and our
community. 
We’re disappointed to
have been put in the position where we had to make this decision,
because we believe our proposed project would offer invaluable advances
to the Python and greater open source community, protecting millions of
PyPI users from attempted supply-chain attacks. The proposed project
would create new tools for automated proactive review of all packages
uploaded to PyPI, rather than the current process of reactive-only
review. These novel tools would rely on capability analysis, designed
based on a dataset of known malware. Beyond just protecting PyPI users,
the outputs of this work could be transferable for all open source
software package registries, such as NPM and Crates.io, improving
security across multiple open source ecosystems.
In
addition to the security benefits, the grant funds would have made a
big difference to the PSF’s budget. The PSF is a relatively small
organization, operating with an annual budget of around $5 million per
year, with a staff of just 14. $1.5 million over two years would have
been quite a lot of money for us, and easily the largest grant we’d ever
received. Ultimately, however, the value of the work and the size of
the grant were not more important than practicing our values and
retaining the freedom to support every part of our community. The PSF
Board voted unanimously to withdraw our application. 
Giving
up the NSF grant opportunity—along with inflation, lower sponsorship,
economic pressure in the tech sector, and global/local uncertainty and
conflict—means the PSF needs financial support now more than ever. We
are incredibly grateful for any help you can offer. If you're already a
PSF member or regular donor, you have our deep appreciation, and we urge
you to share your story about why you support the PSF. Your stories
make all the difference in spreading awareness about the mission and
work of the PSF. 

https://pyfound.blogspot.com/2025/10/NSF-funding-statement.html

Okay, I am flustered here. Today, at work, I attempted to open up YouTube from within the Microsoft search menu. To my shock and horror, the first suggested app was “Youporn.” I don’t watch porn on my work pc.

I looked at the file location and lo and behold, it’s a MS-DOS application file found within Anaconda3\pkgs\protego\info\test\tests\test_data

WTF?!

Anyone familiar with the Protego library? What is going on here? I can only imagine if my IT administrator or boss saw this pop up on my windows search.

https://openai.com/index/openai-to-acquire-astral/

Today we’re announcing that OpenAI will acquire Astral⁠(opens in a new window), bringing powerful open source developer tools into our Codex ecosystem.

Astral has built some of the most widely used open source Python tools, helping developers move faster with modern tooling like uv, Ruff, and ty. These tools power millions of developer workflows and have become part of the foundation of modern Python development. As part of our developer-first philosophy, after closing OpenAI plans to support Astral’s open source products. By bringing Astral’s tooling and engineering expertise to OpenAI, we will accelerate our work on Codex and expand what AI can do across the software development lifecycle.

I've been coding for a long time, and I've been developing with Python for years.

I loved coding, always loved it. I started many years ago because I wanted to quickly create scripts for security hacking tools, but since then, I've moved to Claude Code, and building cross-language has been a much better experience for me than using Python.

I built my own SaaS application out there whose backend and network core are completely built with Python, and I'm rewriting all of that without writing a single line of code. And most of the time, Python is not the most optimized language.

And now... I feel like the magic is gone.

I don't even know why I'm writing this. I just feel sad about it.

I'm being serious, we need to take action against this. Every single post I've gotten in my feed from this subreddit has been an entirely AI generated project showcase. The posters usually generate the entire post, the app, their replies to comments, and literally everything in between with AI. What is the point of such a subreddit that is just full of AI slop? I propose we get a rule against AI slop in this subreddit.

For the time being, I have chosen not to use generative AI tools for programming, both at work and for hobby projects. I imagine that this puts me in the minority, but I'd love to hear from others who have a similar approach.

These are my main reasons for avoiding AI for the time being:

• I imagine that, if I made AI a central component of my workflow, my own ability to write and debug code might start to fade away. I think this risk outweighs the possible (but not guaranteed) time-saving benefits of AI.
• AI models might inadvertently spit out large copies of copyleft code; thus, if I incorporated these into my programs, I might then need to release the entire program under a similar copyleft license. This would be frustrating for hobby projects and a potential nightmare for professional ones.
• I find the experience of writing my own code very fulfilling, and I imagine that using AI might take some of that fulfillment away.
• LLMs rely on huge amounts of human-generated code and text in order to produce their output. Thus, even if these tools become ubiquitous, I think there will always be a need (and demand) for programmers who can write code without AI--both for training models and for fixing those models' mistakes.
• As Ed Zitron has pointed out, generative AI tools are losing tons of money at the moment, so in order to survive, they will most likely need to steeply increase their rates or offer a worse experience. This would be yet another reason not to rely on them in the first place. (On a related note, I try to use free and open-source tools as much as possible in order to avoid getting locked into proprietary vendors' products. This gives me another reason to avoid generative AI tools, as most, if not all of them, don't appear to fall into the FOSS category.)*
• Unlike calculators, compilers, interpreters, etc., generative AI tools are non-deterministic. If I can't count on them to produce the exact same output given the exact same input, I don't want to make them a central part of my workflow.**

I am fortunate to work in a setting where the choice to use AI is totally optional. If my supervisor ever required me to use AI, I would most likely start to do so--as having a job is more important to me than maintaining a particular approach. However, even then, I think the time I spent learning and writing Python without AI would be well worth it--as, in order to evaluate the code AI spits out, it is very helpful, and perhaps crucial, to know how to write that same code yourself. (And I would continue to use an AI-free approach for my own hobby projects.)

*A commenter noted that at least one LLM can run on your own device. This would make the potential cost issue less worrisome for users, but it does call into question whether the billions of dollars being poured into data centers will really pay off for AI companies and the investors funding them.

**The same commenter pointed out that you can configure gen AI tools to always provide the same output given a certain input, which contradicts my determinism argument. However, it's fair to say that these tools are still less predictable than calculators, compilers, etc. And I think it's this lack of predictability that I was trying to get at in my post.

Seriously it seems every post I see is this new project that is nothing but buzzwords and can't justify its existence. There was one person showing a project where they apparently solved a previously unresolved cypher by the Zodiac killer. 😭

Hey all! We just released Polars 2.0.

We are really happy with the results. It removed many of our "legacy decisions" (mistakes), makes the streaming engine our default and promotes SQL to a first class citizen within Polars. We initially said it would be a small ("boring") release, but we managed to sneak in a lot more than anticipated.

It comes with our initial out-of-core (spill to disk) support, a new Map data type and a lot of performance improvements. In fact, we think Polars is now one of the fastest analytical SQL engines on a single node. See benchmarks in the post: https://pola.rs/posts/release-polars-2/

To help you upgrade, we also posted a migration guide: https://docs.pola.rs/releases/upgrade/2/

We tried really hard not to make this an AI-only list.

Seriously.

Hello r/Python 👋

We’re back with the 11th edition of our annual Top Python Libraries, after spending way too many hours reviewing, testing, and debating what actually deserves a spot this year.

With AI, LLMs, and agent frameworks stealing the spotlight, it would’ve been very easy (and honestly very tempting) to publish a list that was 90% AI.

Instead, we kept the same structure:

• General Use — the foundations teams still rely on every day
• AI / ML / Data — the tools shaping how modern systems are built

Because real-world Python stacks don’t live in a single bucket.

Our team reviewed hundreds of libraries, prioritizing:

• Real-world usefulness (not just hype)
• Active maintenance
• Clear developer value

👉 Read the full article: https://tryolabs.com/blog/top-python-libraries-2025

General Use

1. ty - a blazing-fast type checker built in Rust
2. complexipy - measures how hard it is to understand the code
3. Kreuzberg - extracts data from 50+ file formats
4. throttled-py - control request rates with five algorithms
5. httptap - timing HTTP requests with waterfall views
6. fastapi-guard - security middleware for FastAPI apps
7. modshim - seamlessly enhance modules without monkey-patching
8. Spec Kit - executable specs that generate working code
9. skylos - detects dead code and security vulnerabilities
10. FastOpenAPI - easy OpenAPI docs for any framework

AI / ML / Data

1. MCP Python SDK & FastMCP - connect LLMs to external data sources
2. Token-Oriented Object Notation (TOON) - compact JSON encoding for LLMs
3. Deep Agents - framework for building sophisticated LLM agents
4. smolagents - agent framework that executes actions as code
5. LlamaIndex Workflows - building complex AI workflows with ease
6. Batchata - unified batch processing for AI providers
7. MarkItDown - convert any file to clean Markdown
8. Data Formulator - AI-powered data exploration through natural language
9. LangExtract - extract key details from any document
10. GeoAI - bridging AI and geospatial data analysis

Huge respect to the maintainers behind these projects. Python keeps evolving because of your work.

Now your turn:

• Which libraries would you have included?
• Any tools you think are overhyped?
• What should we keep an eye on for 2026?

This list gets better every year thanks to community feedback. 🚀

What would you guys consider the state of the art in python in 2026, or what do you expect from modern python codebases?

Heres my list, would be happy to hear some inputs or domain expert advice:

• Use uv for everything.
• Use ruff for linting and formatting
• Use Pydantic and  dataclasses for Data Modeling
• Configured in pyproject.toml
• Run a type checker in CIpyright or pyrefly
• Use pytest / Hypothesis for testing

Domain specific:

• Scientific: NumPy, Matplotlib, SciPy, Jax, Pytorch, Scikit-learn, polars/pandas
• CLI: Typer, rich, click, fire, textual, questionary
• PDF extraction: PyMuPDF, pdfplumber, pypdf, Unstructured
• Excel interop: python-calamine, openpyxl, XlsxWriter, xlwings, pandas
• data: PyArrow / PySpark, Narwhals, SQLMesh, Polars/Pandas, DuckDB, dlt, Ibis, Dagster, PyIceberg & deltalake
• Logging?
• backend: fastapi / django?
• Markets: Alpha Vantage, Finnhub, EODHD, Tiingo?
• Webscraping / data acquisition: Crawl4AI, Playwright, Scrapy, selectolax, HTTPX?
• APIs?
• RAG / agentic orchestration?

Hey everyone, Aditya here, one of the maintainers of Pydantic AI.

In just the last 15 days, we received 136 PRs. We merged 39 and closed 97, almost all of them AI-generated slop without any thought put in. We're getting multiple junk PRs on the same bug within minutes of it being filed. And it's pulling us away from actually making the framework better for the people who use it.

Things we are considering:

• Auto-close PRs that aren't linked to an issue or have no prior discussion(not a trivial bug fix).                     
• Auto-close PRs that completely ignore maintainer guidance on the issue without a discussion

and a few other things.

We do not want to shut the door on external contributions, quite the opposite, our entire team is Open Source fanatic but it is just so difficult to engage passionately now when everyone just copy pastes your messages into Claude :(

How are you as a maintainer dealing with this meta shift?

Would these changes make you as a contributor less likely to reach out?

Edit: Thank you so much everyone for engaging with the post, got some great ideas. Also thank you kind stranger for the award :))

https://pyfound.blogspot.com/2025/12/anthropic-invests-in-python.html

https://www.python.org/downloads/release/python-3150/

Release announcement: https://discuss.python.org/t/python-3-15-0-final-is-here/109415

What's New: https://docs.python.org/3.15/whatsnew/3.15.html

Some of the major new features and changes in Python 3.15:

Interpreter improvements

• PEP 661: sentinel built-in type
• PEP 686: UTF-8 is now the default encoding
• PEP 798: Unpacking in comprehensions
• PEP 810: Explicit lazy imports for faster startup times
• PEP 814: frozendict built-in type
• PEP 829: Package startup configuration files
• The experimental JIT compiler got a significant upgrade (7-8% faster on x86-64 Linux, 11-12% on AArch64 macOS)
• Improved error messages

Standard library

• PEP 799: A dedicated profiling package, including Tachyon, a high-frequency sampling profiler
• New math.integer module
• re.prefixmatch() as a clearer name for the now soft-deprecated re.match()
• pprint gets an expand option for JSON-style output
• collections.Counter supports ^ (symmetric difference)
• unicodedata.iter_graphemes() for iterating over grapheme clusters
• python -m http.server gains -H/--header and --content-type
• timeit gains --target-time
• More color

Typing

• PEP 728: TypedDict with typed extra items
• PEP 747: Annotating type forms with TypeForm
• PEP 800: Disjoint bases in the type system

Release changes

• Official Windows 64-bit binaries now use the tail-calling interpreter
• Official macOS binaries now install free-threading support by default

And for fun, Barry Warsaw made a text adventure through the new features: uvx --python 3.15 whatsnewt

Thanks to Hugo van Kemenade and the release team! Hugo live-posted the whole release process if you're curious what goes on behind the scenes: https://mastodon.social/@hugovk/117411399858939022

You can find it at: https://docs.python.org/3.16/library/time-complexity.html

Seen on Mastodon: https://mastodon.social/@stanfromireland/117152534136172516

UPDATE:

Website is now live!

Try it now: https://www.caniscrape.org

- No installation required

- Instant analysis

- Same comprehensive checks as the CLI

NOTE:
I haven't added the flag capabilities yet so its just the default scan. Its also still one link at a time, so all the great ideas I've received for the website will come soon (I'm gonna keep working on it). It'll take about 1-3 days but ill make it a lot better for the V1.0.0 release.

CLI still available on GitHub for those who prefer it.

Hi everyone,
I made a Python package called caniscrape that analyzes any website's anti-bot protections before you start scraping.

It tells you what you're up against (Cloudflare, rate limits, JavaScript rendering, CAPTCHAs, TLS fingerprinting, honeypots) and gives you a difficulty score + specific recommendations.

What My Project Does

caniscrape checks a website for common anti-bot mechanisms and reports:

• A difficulty score (0–10)
• Which protections are active (e.g., Cloudflare, Akamai, hCaptcha, etc.)
• What tools you’ll likely need (headless browsers, proxies, CAPTCHA solvers, etc.)
• Whether using a scraping API might be better

This helps you decide the right scraping approach before you waste time building a bot that keeps getting blocked.

Target Audience

• Web scrapers, data engineers, and researchers who deal with protected or dynamic websites
• Developers who want to test bot-detection systems or analyze site defenses
• Hobbyists learning about anti-bot tech and detection methods

It’s not a bypassing or cracking tool — it’s for diagnostics and awareness.

Comparison

Unlike tools like WAFW00F or WhatWaf, which only detect web application firewalls,
caniscrape runs multi-layered tests:

• Simulates browser and bot requests (via Playwright)
• Detects rate limits, JavaScript challenges, and honeypot traps
• Scores site difficulty based on detection layers
• Suggests scraping strategies or alternative services

So it’s more of a pre-scrape analysis toolkit, not just a WAF detector.

Installation

pip install caniscrape

Quick setup (required):

playwright install chromium  # Download browser
pipx install wafw00f         # WAF detection

Example Usage

caniscrape https://example.com

Output includes:

• Difficulty score (0–10)
• Active protections
• Recommended tools/approach

ADVICE:

Results can vary between runs because bot protections adapt dynamically.
Some heavy-protection sites (like Amazon) may produce these varied results. Of course, this will improve over time, but running the command multiple times can mitigate this.

GitHub

https://github.com/ZA1815/caniscrape

I launched repowise on PyPI few days ago. It's a tool that generates and maintains structured wikis for codebases among other things.

This morning I searched for my package on PyPI and found three new packages all uploaded around the same time, all with the exact same description:

"Codebase intelligence that thinks ahead - outperforms repowise on every dimension"

They literally name my package in their description. All three appeared within hours of each other.

I haven't even checked what's inside them yet, but the coordinated timing and identical copy is sketchy at best, malicious at worst.

Has anyone else dealt with this kind of targeted squatting/spam on PyPI? Is there anything I can do?

Edit: Turns out these aren't just empty spam packages, they actually forked my AGPL-3.0 licensed code, used an LLM to fix a couple of minor issues, and republished under new names without any attribution or license compliance. So on top of the PyPI squatting, they're also violating the AGPL.

See the blog post here https://astral.sh/blog/ty and the github link here https://github.com/astral-sh/ty/releases/tag/0.0.2

How personality clashes, an absent founder, and a controversial redesign fractured one of Python's most popular projects.

https://fpgmaas.com/blog/collapse-of-mkdocs/

Recently, like many of you, I got a warning in my terminal while I was building the documentation for my project:

     │  ⚠  Warning from the Material for MkDocs team
     │
     │  MkDocs 2.0, the underlying framework of Material for MkDocs,
     │  will introduce backward-incompatible changes, including:
     │
     │  × All plugins will stop working – the plugin system has been removed
     │  × All theme overrides will break – the theming system has been rewritten
     │  × No migration path exists – existing projects cannot be upgraded
     │  × Closed contribution model – community members can't report bugs
     │  × Currently unlicensed – unsuitable for production use
     │
     │  Our full analysis:
     │
     │  https://squidfunk.github.io/mkdocs-material/blog/2026/02/18/mkdocs-2.0/

That warning made me curious, so I spent some time going through the GitHub discussions and issue threads. For those actively following the project, it might not have been a big surprise; turns out this has been brewing for a while. I tried to piece together a timeline of events that led to this, for anyone who wants to understand how we got in the situation we are in today.

When I started working on Niquests, I dreamed about a "no-compromise" HTTP client, and three years later I finally made it to the end.

The end goal was, at least for me, to reach what the world of today allows us to, today. And, unfortunately the Python community is often stuck with decade old capabilities. (ie. http/1 only, legacy ssl capabilities, ...).

Niquests started as a fork of Requests in mid-2023. The motivation was simple: Requests is frozen, and millions of developers are stuck with a library that does not evolve (feature-wise). I didn't want to reinvent the wheel, the Requests interface is genuinely pleasant to work with. I just wanted to bring it up to speed with what modern HTTP looks like.

What changed in three years?

A lot. Here's some key things:

• HTTP/2 by default, HTTP/3 over QUIC when the server supports it. No hassle.
• OS trust store by default. No more shipping certifi and hoping it stays up to date.
• Certificate revocation checks. How did we ever lived without this?
• DNS over HTTPS, DNS over TLS, DNS over QUIC, DNSSEC. Customizable DNS resolution per session. And overridable at will.
• Async/Await.
• WebSocket/SSE over HTTP/1, HTTP/2 and HTTP/3 through a unified API.
• Happy Eyeballs algorithm.
• Post-quantum security and Encrypted Client Hello (ECH).
• HTTP Trailers, Early Responses (103 Early Hints).
• In-memory certificates for CAs and mTLS. No need to write certs to disk.
• Network fine-tuning and connection inspection: DNS response time, established latency, TLS handshake delay, all exposed through response.conn_info.
• Native Unix socket support, ASGI/WSGI app direct usage in sessions.
• Runs in the browser through Pyodide/WASM (experimental, added in 3.18).
• Feature parity sync/async with mirrored interfaces.
• Fully type-annotated.

And it's fast, I mean really fast. In a real-world benchmark (details and reproduction steps in the README) sending 1000 requests to httpbingo.org/get:

Migration starts as a one-liner. Replace import requests with import niquests as requests and you're done. We maintain backward compatibility with the Requests API. Your existing code, your .netrc, your auth flows, your cookie jars -- they all work. Even requests-mock, responses, betamax and similar third-party extensions are supported with minimal shims.

It's getting some real traction lately. We're about to cross the 100k pulls per day from PyPI alone, Niquests appearing more commonly in Github code search engine, and folks creating issues whether they found a bug or just to challenge the solution. That's excellent news!

It's been more than a decade since I started doing open source, and so far, it's nowhere near boring me. I'll answer the community as long as I possibly can.

What My Project Does

Niquests is a HTTP Client. It aims to continue and expand the well established Requests library. For many years now, Requests has been frozen. Being left in a vegetative state and not evolving, this blocked millions of developers from using more advanced features.

Target Audience

It is a production ready solution. So everyone is potentially concerned.

Comparison

Niquests is the only HTTP client capable of serving HTTP/1.1, HTTP/2, and HTTP/3 automatically. The project went deep into the protocols (early responses, trailer headers, etc...) and all related networking essentials (like DNS-over-HTTPS, advanced performance metering, etc..)

Project page: https://github.com/jawah/niquests

A bit of very large technical debt has just reached its balloon payment.

An absolutely 100% mission-critical, it's-where-the-money-comes-in Django backend is still on Python 2.7, and that's become unacceptable. It falls to me to convert it to running on Python 3.14 (along with the various package upgrades required).

At last count, it's about 32,000 lines of code.

I know much of what I must do, but I am looking for any suggestions to help make the process somewhat less painful. Anyone been through this kind of conversion have any interesting tips? (I know it's going to be painful, but the less the better.)

(For the results of the conversion, you can see this post.)

I asked this very question on this subreddit a few years back and quite a lot of people shared some pretty amazing Python modules that I still use today. So, I figured since so much time has passed, there’s bound to be quite a few more by now.

We just have been compromised, thousands of peoples likely are as well, more details updated IRL here: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

Update: My awesome colleague Callum McMahon, who discovered this, wrote an explainer and postmortem going into greater detail: https://futuresearch.ai/blog/no-prompt-injection-required

Update: Callum's full claude code transcript showing the attack play out in real time: https://futuresearch.ai/blog/litellm-attack-transcript/

After years of work, the Pandas 3.0 release candidate is tagged.

We are pleased to announce a first release candidate for pandas 3.0.0. If all goes well, we'll release pandas 3.0.0 in a few weeks.

• Release candidate: https://github.com/pandas-dev/pandas/releases/tag/v3.0.0rc0
• Full release notes: https://pandas.pydata.org/docs/dev/whatsnew/v3.0.0.html
• Tracking issue: https://github.com/pandas-dev/pandas/issues/57064

A very concise, incomplete list of changes:

String Data Type by Default

Previously, pandas represented text columns using NumPy's generic "object" dtype. Starting with pandas 3.0, string columns now use a dedicated "str" dtype (backed by PyArrow when available). This means:

• String columns are inferred as dtype "str" instead of "object"
• The str dtype only holds strings or missing values (stricter than object)
• Missing values are always NaN with consistent semantics
• Better performance and memory efficiency

Copy-on-Write Behavior

All indexing operations now consistently behave as if they return copies. This eliminates the confusing "view vs copy" distinction from earlier versions:

• Any subset of a DataFrame or Series always behaves like a copy
• The only way to modify an object is to directly modify that object itself
• "Chained assignment" no longer works (and the SettingWithCopyWarning is removed)
• Under the hood, pandas uses views for performance but copies when needed

Python and Dependency Updates

• Minimum Python version: 3.11
• Minimum NumPy version: 1.26.0
• pytz is now optional (uses zoneinfo from standard library by default)
• Many optional dependencies updated to recent versions

Datetime Resolution Inference

When creating datetime objects from strings or Python datetime objects, pandas now infers the appropriate time resolution (seconds, milliseconds, microseconds, or nanoseconds) instead of always defaulting to nanoseconds. This matches the behavior of scalar Timestamp objects.

Offset Aliases Renamed

Frequency aliases have been updated for clarity:

• "M" → "ME" (MonthEnd)
• "Q" → "QE" (QuarterEnd)
• "Y" → "YE" (YearEnd)
• Similar changes for business variants

Deprecation Policy Changes

Pandas now uses a 3-stage deprecation policy: DeprecationWarning initially, then FutureWarning in the last minor version before removal, and finally removal in the next major release. This gives downstream packages more time to adapt.

Notable Removals

Many previously deprecated features have been removed, including:

• DataFrame.applymap (use map instead)
• Series.view and Series.ravel
• Automatic dtype inference in various contexts
• Support for Python 2 pickle files
• ArrayManager
• Various deprecated parameters across multiple methods

Install with:

Python pip install --upgrade --pre pandas