fix(types): remove definition of StrEnum as Enum

[fisher60]

This addresses an issue with typing where string enums generated by prisma are not compatible with str typing. This specifically fixes an issue where Pyright checks would fail since prisma StrEnum has type Enum, which is not valid as a str.

Change Summary

Please summarise the changes this pull request is making here.

Checklist

• Unit tests for the changes exist
• Tests pass without significant drop in coverage
• Documentation reflects changes where applicable
• Test snapshots have been updated if applicable

Agreement

By submitting this pull request, I confirm that you can use, modify, copy and redistribute this contribution, under the terms of your choice.

[RobertCraigie]

Thanks, can you add type checking tests for this? https://prisma-client-py.readthedocs.io/en/stable/contributing/contributing/#type-tests

You'll have to create a new file at typesafety/pyright/types/enums.py and use the Role enum.

[RobertCraigie]

I think we still need the TYPE_CHECKING block, linters unfortunately do not like try except for imports like this :(

e.g.

if TYPE_CHECKING:
  if sys.version < (3, 11):
    from strenum import StrEnum as StrEnum
  else:
    from enum import StrEnum as StrEnum
else:
  # ... original try catch

[fisher60]

Thanks, can you add type checking tests for this?

I am looking into this. Are there specific tests you have in mind that are not covered by other locations that utilize enums? i.e lists.py has several locations where it utilizes enums. Do we want more involved tests than are covered here? Or some similar tests explicitly made for enums?

[fisher60]

Is there a benefit to maintaining the original try-except if the if-else statement handles checking python versions and importing the StrEnum?

[RobertCraigie]

Is there a benefit to maintaining the original try-except if the if-else statement handles checking python versions and importing the StrEnum?

That's a good point, I have a personal bias towards keeping the try-except but not for any logical reasons so feel free to just use the if statement 😅

[RobertCraigie]

I am looking into this. Are there specific tests you have in mind that are not covered by other locations that utilize enums? i.e lists.py has several locations where it utilizes enums. Do we want more involved tests than are covered here? Or some similar tests explicitly made for enums?

I was thinking similar tests explicitly for enums, for example, the most important one would be a test case for the example code you shared before that broke when we were using StrEnum = Enum.

[RobertCraigie]

Looks like mypy is reporting errors from the strenum library??

[RobertCraigie]

The pyright lint failure in CI is likely because we're using 3.11 to run & install dependencies but targeting 3.7, IIRC we can't use 3.7 to install dependencies because some dev dependencies have dropped support for 3.7 and I didn't want to drop 3.7 support until there was a user-facing need to do so.

I think this'll be a problem for me as well locally as I use 3.11 when developing, so I think the solution would be to add strenum to our internal dev dependencies at pipelines/requirements/dev.txt.

[RobertCraigie]

@fisher60 the lint error is because you need to import StrEnum as StrEnum 🙃

[RobertCraigie]

hmm looks like mypy really doesn't like our usage of strenum... maybe we should just revert to the previous enum definition at the type-level as the only issues that had were at runtime, e.g.

if TYPE_CHECKING:
  if sys.version_info >= (3, 11):
    from enum import StrEnum as StrEnum
  else:
    class StrEnum(str, Enum):
      ...
else:
  if sys.version_info >= (3, 11):
    from enum import StrEnum as StrEnum
  else:
    from strenum import StrEnum as StrEnum

[RobertCraigie]

Thank you!!