Skip to content

✨ Allow None as return type for bodiless responses - #9425

Merged
tiangolo merged 5 commits into
fastapi:masterfrom
hofrob:fix-return-no-content-future-annotations
Sep 20, 2025
Merged

✨ Allow None as return type for bodiless responses#9425
tiangolo merged 5 commits into
fastapi:masterfrom
hofrob:fix-return-no-content-future-annotations

Conversation

@hofrob

@hofrob hofrob commented Apr 21, 2023

Copy link
Copy Markdown
Contributor

Fixes #9424

If the return annotation of the route function is exactly "None", return None for the typed annotation. This allows the status code 204 No Content to be used.

@github-actions

This comment was marked as outdated.

@github-actions

github-actions Bot commented Jun 6, 2023

Copy link
Copy Markdown
Contributor

📝 Docs preview for commit bb5ef4a at: https://647f33cb7357732441e2ff02--fastapi.netlify.app

@fnep

fnep commented Jun 24, 2023

Copy link
Copy Markdown

I tested this using pip install git+https://github.com/hofrob/fastapi@fix-return-no-content-future-annotations and it fixes my issue in #9723. 👍

@hofrob

hofrob commented Jul 18, 2023

Copy link
Copy Markdown
Contributor Author

@csbasil I rebased after you approved it.

Are there any plans on merging this PR?

@Kludex Kludex changed the title fix: allow None as return type for http 204 🐛 Allow None as return type for bodiless responses Jul 18, 2023
@Kludex

This comment was marked as outdated.

@hofrob

hofrob commented Jul 18, 2023

Copy link
Copy Markdown
Contributor Author

There's an alternative to this on #5860.

Yes, I thought it's not necessary to get the actual type in this case, since None is a reserved word anyway.

It might be a bit faster to compare the string further up in the stack, but that's probably negligible.

There may be other arguments about using one over the other.

@tiangolo tiangolo changed the title 🐛 Allow None as return type for bodiless responses ✨ Allow None as return type for bodiless responses Jan 9, 2024
@tiangolo tiangolo added the feature New feature or request label Jan 9, 2024
@jc-louis

Copy link
Copy Markdown

@tiangolo can we get this merged? it will fix this issue 🙏

@YuriiMotov YuriiMotov left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment thread tests/test_return_none_future_annotations.py Outdated
@hofrob
hofrob force-pushed the fix-return-no-content-future-annotations branch from 5ef537b to 4bddd72 Compare June 27, 2025 08:05
@hofrob

hofrob commented Jun 27, 2025

Copy link
Copy Markdown
Contributor Author

Rebased on top of current master branch. 3.14 will enable deferred evaluation of annotations (PEP649) by default.

@YuriiMotov

This comment was marked as off-topic.

@YuriiMotov
YuriiMotov self-requested a review June 27, 2025 08:29
@Kludex

This comment was marked as off-topic.

@YuriiMotov

This comment was marked as off-topic.

@tiangolo

Copy link
Copy Markdown
Member

Thanks! ☕

I tweaked the implementation to not depend on a literal "None" string and instead handle the NoneType that was not being handled. I also tweaked the test to simplify it and use explicit stringified return types to not depend on the possibly changing behavior of from __future__ import annotations. This is now ready. 🤓 🚀

@tiangolo
tiangolo enabled auto-merge (squash) September 20, 2025 18:44
@tiangolo
tiangolo merged commit b51ec36 into fastapi:master Sep 20, 2025
29 checks passed
Glinte added a commit to FYP-PeerAssessment/fyp-backend that referenced this pull request Sep 22, 2025
Glinte added a commit to FYP-PeerAssessment/fyp-backend that referenced this pull request Sep 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Using PEP 649 annotations with status code 204 No Content and return type None raises AssertionError

7 participants