Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use StrEnum from the standard library if available #6

Closed
wants to merge 2 commits into from

Conversation

tmke8
Copy link
Contributor

@tmke8 tmke8 commented Dec 16, 2022

This allows people to just import from backports.strenum on Python 3.11 and still get the version from the standard library. Otherwise you need the if statement on every import.

I used if sys.version_info >= (3, 11) instead of try: from enum import StrEnum; except ImportError ... because static type checkers know how to interpret the former, but struggle with the latter. And it seems it won't get fixed. See for example this comment on mypy: python/mypy#1153 (comment)

This allows people to just import from `backports.strenum`
on Python 3.11 and still get the version from the standard
library. Otherwise you need the if statement on every
import.

I used `if sys.version_info >= (3, 11)` instead of
`try: from enum import StrEnum` because static type checkers know how to
interpret the former, but struggle with the latter.
@clbarnes
Copy link
Owner

I had considered something like this but wondered if it were best handled at the application level, i.e. users of the library doing

try:
    from enum import StrEnum
except ImportError:
    from backports.strenum import StrEnum

Do you happen to know if other backports libraries tend to default to the stdlib internally, or if they leave it to the dependents? The root backports package advises against the former.

@tmke8
Copy link
Contributor Author

tmke8 commented Dec 16, 2022

Hm, interesting. I can definitely see that this wouldn't be recommended if the backported functionality is not exactly the same. The only backported package I ever really used was dataclasses for Python 3.6 but this wasn't an issue there because the import path (from dataclasses import dataclass) was the same in both cases, so there was no need for a guarded import.

I don't know. I lean towards putting the fallback into the package, but I can totally understand if you don't want to do this.

One thing I would advise against though is doing it with a try: ... except ImportError because mypy doesn't like that.

@clbarnes
Copy link
Owner

I suspect that we will end up in a situation where the functionality won't be exactly the same - not least because Enums (including StrEnums) will have some changes between 3.11 and 3.12 (with regards to how __contains__ works, for one). Whether a backport package should reflect the most recent behaviour, or the behaviour of the first stdlib version to make the backport package unnecessary, is possibly subjective. I'd lean towards the latter, as anyone who supports 3.11 and 3.12 will need to account for it in their own library, and IMO the backport should exist as a crutch for people stuck on old versions rather than a long-term structural element like six. Also it's less work going forward 😅

One thing I would advise against though is doing it with a try: ... except ImportError because mypy doesn't like that.

Ah, another instance of idiomatic python disagreeing with tools which make python behave like a "real programming language". But point taken! I'll update the README to use the version check too.

@clbarnes
Copy link
Owner

clbarnes commented Feb 7, 2023

I've mulled this over a bit and I think we should leave it to the application level. But thank you for your contribution!

@clbarnes clbarnes closed this Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants