Feature request: Enum Constants #689
Comments
|
I would very much like to see you have something like this: https://github.com/dj-stripe/dj-stripe/blob/master/djstripe/enums.py |
|
Hello, I am closing this issue as "not planned". As of v7.1.0 last October, we have type annotations that include enums. This isn't quite the same thing as enum constants -- but it provides a lot of the benefit, i.e. IDE autocomplete, preventing you from typo-ing the enum value, letting you see the available options. The names for enum constants can get quite unwieldy especially when they inside some deeply nested property. We are pretty confident in this decision, but feel free to continue discussing and detailing your use cases if you believe this is a mistake. |
|
Thank you @richardm-stripe, I think it's a good alternative. |
Uh oh!
There was an error while loading. Please reload this page.
It may be useful to provide constant definitions for the enum values in the API, as we do for stripe-php. See #688 for an example of what this might look like.
There are some downsides to this. In particular this would result in more breaking changes to
stripe-pythonwhenever an enum's values changed/were renamed. If we generated the enum values, stripe-python would only ever include the latest enum values for a particular field in the API (even though the API does support old enum values), and I worry this would discourage users from upgrading.Adding the enums also represents a perpetual increase in the work required to maintain the library and keep it up
to date, and this trades off against us being able to make other improvements to the library.
It also seems that this would be less useful in a world where we shipped MyPy types, which is something that we are considering.
In any case, we aren't planning on adding this for the time being, but we'll keep the github issue open as a place for users to share their thoughts (and thumbs).
The text was updated successfully, but these errors were encountered: