Conversation
|
@justanr how do you feel about this PR? If this is good, then I (or someone else, such as @Birne94, @quaterneon, or @h) can come back and add ApiSpec support to this class |
|
@justanr Any feedback? Almost a month now and no response. Is this repo still maintained? |
|
@justanr I would be very grateful if you could review this PR and either approve it, or let me know what needs to change. |
|
I retargeted the branch to a next-releases branch (collecting all changes that should go in) there's now 1 small conflict (make_error needs to move to EnumField fail method). Happy to resolve that myself or if you want to. |
|
@justanr I think I resolved the conflict. Let me know if there is anything else that needs to be updated. Thanks! |
|
👍 danke for the extreme patience. |
|
I've used the version from #38 successfully with OpenAPI spec, and would very much appreciate if it could be merged, and a release published, eventually :) 👍 |
One of the issues that is holding up adding ApiSpec support is that EnumField can support different behaviour for
load_byanddump_by. This can be seen in #24, #25, #27, #38This PR adds a StrictEnumField which removes that behaviour while retaining backwards compatibility with the current EnumField.
If this PR is approved, then we should be able to add the ApiSpec support to this strict field, and anyone that would like to have ApiSpec support should switch to this one.