Resolve inconsistencies with use of `BlenderTypeEnum` and `prefix_values_with`-on-`StrEnum` #43

New Issue

Open

opened 2024-05-05 09:37:37 +02:00 by so-rose · 0 comments

so-rose commented

2024-05-05 09:37:37 +02:00

Owner

We use both to define enums with common prefixes / custom functionality, but tend to strictly prefer StrEnum.

The only show-stopper when it comes to migrating everything to prefix_values_with is that it does not propagate methods defined on the original class to the new class. It's a surprisingly non-trivial thing to fix; see the enum docs (https://docs.python.org/3/library/enum.html).

We either need to fix this limitation of prefix_values_with and migrate all uses of BlenderTypeEnum (including removing now-spurious uses of .values on all sockets / nodes), or do something else. In any case, blender_type_enum.py is a really unfortunate bit of code to keep around.

We use both to define enums with common prefixes / custom functionality, but tend to strictly prefer `StrEnum`. The only show-stopper when it comes to migrating everything to `prefix_values_with` is that **it does not propagate methods defined on the original class to the new class**. It's a surprisingly non-trivial thing to fix; see the enum docs (<https://docs.python.org/3/library/enum.html>). We either need to fix this limitation of `prefix_values_with` and migrate all uses of `BlenderTypeEnum` (including removing now-spurious uses of `.values` on all sockets / nodes), or do something else. In any case, `blender_type_enum.py` is a really unfortunate bit of code to keep around.