Codecov Report

Merging #2061 (fffd897) into master (3de0fb8) will not change coverage.
The diff coverage is 100.00%.

❗ Current head fffd897 differs from pull request most recent head a7efa6a. Consider uploading reports for the commit a7efa6a to get more accurate results

@@             Coverage Diff             @@
##            master     #2061     +/-   ##
===========================================
  Coverage   100.00%   100.00%             
===========================================
  Files          509       243    -266     
  Lines        12807      7428   -5379     
===========================================
- Hits         12807      7428   -5379     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3de0fb8...a7efa6a. Read the comment docs.

📝 Docs preview for commit e85b8e86880ef1da23a4c2e6a39535499c8eb3ff at: https://5f61bb0c6d3cd4463e8e5c14--fastapi.netlify.app

📝 Docs preview for commit 379762189f4ac877ae9ec32214fc0008a6fe40ba at: https://5f629ba0924ff0920a89f626--fastapi.netlify.app

Hi @ycd - thanks for approving. Just wondering when PRs are typically merged in & what the process is. Is there anything else needed from me in order to get this merged in?

Just wait for @tiangolo 's input.

Exactly, @tiangolo usually releases a new version in 14-21 days, but he just recently moved to Germany so he is probably too busy too look here, but i believe next release would not take longer than 1-2 weeks.

Gotcha, not a problem at all! Thanks @ycd & @Kludex :)

Hello! This does appear to fix my issue at #2091. However, if I may make one suggestion to this PR, please also fix the mutable dictionary that is set as a keyword argument with this code:

    custom_encoder: dict = None,     # <------- Make this change
    sqlalchemy_safe: bool = True,
) -> Any:
    custom_encoder = custom_encoder or {}       # <-------- And this change
    if custom_encoder:
        if type(obj) in custom_encoder:
            return custom_encoder[type(obj)](obj)
        else:
            for encoder_type, encoder in custom_encoder.items():
                if isinstance(obj, encoder_type):
                    return encoder(obj)

More details on this is here: https://docs.python-guide.org/writing/gotchas/#mutable-default-arguments

Hello! This does appear to fix my issue at #2091. However, if I may make one suggestion to this PR, please also fix the mutable dictionary that is set as a keyword argument with this code:

    custom_encoder: dict = None,     # <------- Make this change
    sqlalchemy_safe: bool = True,
) -> Any:
    custom_encoder = custom_encoder or {}       # <-------- And this change
    if custom_encoder:
        if type(obj) in custom_encoder:
            return custom_encoder[type(obj)](obj)
        else:
            for encoder_type, encoder in custom_encoder.items():
                if isinstance(obj, encoder_type):
                    return encoder(obj)

More details on this is here: https://docs.python-guide.org/writing/gotchas/#mutable-default-arguments

I agree! I can make this change if there are no objections.

📝 Docs preview for commit a92f760b66ecf936ad3bee568c7115220a3e3da8 at: https://5f736b1a6789f9014b8f9245--fastapi.netlify.app

Hate to be a bother @ycd :) but just bumping this because I made the change @mikegrima suggested.

Also, do we think this is going to be merged in soon? Trying to decide if I should use my personal fork to use this change (which I'd rather not on the off-chance that this change doesn't actually get merged in)

Would like to make a friendly bump to get this released soon.

Hi @tiangolo - We (and others) would really like to use this ASAP. Really appreciate it if you could review this & lmk if good.

Hello. Is there something preventing this from being merged? It's been open for a while now and we really need this change!

@viveksunder Can you rebase this PR?

@ycd one this is rebased, can you merge it in?

📝 Docs preview for commit 3a89879740e47c8760f9ed863e59b5ebef9fc253 at: https://5fe41162b6d01b7e356fabee--fastapi.netlify.app

My git commit history got borked while rebasing 🤕 so I started a new one here - #2567

Never mind, github is pretty smart & turns out I didn't need to open a new one.

📝 Docs preview for commit fffd897 at: https://5fe42059b6d01baf796fa7df--fastapi.netlify.app

📝 Docs preview for commit fffd897 at: https://5fe42118605fe19c1aa29afe--fastapi.netlify.app

@mikegrima I'd love to do it but the only @tiangolo can merge PR's.

Really looking forward to this, any news from @tiangolo ?

@tiangolo Friendly bump to merge.

@tiangolo Do you see any problems with the approach implemented here? Sometimes it's really useful to override the default encoder. E.g. encoding Decimals to json using a predefined quantization. Would be really great if you would accept this PR

+1 would really like to have a custom Enum serializer. @tiangolo

@tiangolo please click merge. The PR fixes a bug.

EDIT: Sorry if this came off too strong (that was not my intention).

Is this PR still necessary?

For my usecase at least, it seems like the following resolved.
#1769

Probably there's a different one I'm not understanding :)

@philipbjorge indeed it is still needed, the check for isinstance(obj, Enum) in fastapi/encoders.py is performed before checking whether custom encoders exist, therefore it is currently impossible to create a functional custom encoder for an Enum type.

For me this is very necessary, as I work with DynamoDB and it requires floats to be transformed to Decimal in the boto3 library.

My current solution makes another iteration on top of the result of jsonable_encoder to fix floats, quite unoptimal

Can someone please reach out to @tiangolo to get this merged in? This fixes a legitimate bug and adds a desirable feature for a number of users.

@tiangolo is there anything else we can do to get this PR over the line and merged in?

I too have the same issue as @mikegrima and can verify this PR fixes my issue by allowing the user to specify custom json_encoders for Enums. Simply doing enum.value doesn't produce JSONable values for nested Enums.

waiting for this to be merged as well. @tiangolo could you please look at it?

It will be fantastic to iron out this very surprising behavior and incompatibility between FastAPI and pydantic! Trying to implement pydantic/pydantic#1004 for my API at the moment and it relies on custom encoders working expectedly. @tiangolo

+1 It will be very helpful to fix this. For instance, I'm trying to use fastapi with Mongodb, and I'am having trouble with the Decimal128 type for pymongo.bson which is not natively supported by pydantic, so I would need to provide a custom serialization. The problem seems to be with collection types like sets, lists, etc. @tiangolo

Also waiting on this fix, wondering what is holding it up? @ycd @JP-Globality @tiangolo ?

I needed to implement custom encoder for decimal and enum types, but I couldn't. I am looking forward to this PR merged.

@tiangolo please merge this. My team rely on FastAPI and Pydantic quite heavily. Having to write custom types and using type ignores is not the best. Would be great if this can get merged into the next release!

📝 Docs preview for commit a7efa6a at: https://61ed82f4bc4aa1c45bb3b669--fastapi.netlify.app

Awesome, thank you @viveksunder! ☕

And thanks everyone for the interest! 🍰

This is available in FastAPI 0.73.0, released in a couple of hours. 🎉