Wrapping VTK’s enums as enum.Enum is not currently planned. I imagine that the main feature that you require is the ability to iterate over the enum members. If so, that is something that I could easily add to the current implementation. Moving over to enum.Enum would entail a fair bit more work, so it could be put on the roadmap, but I’m not sure when it could actually be done.
Can you provide additional details about your requirements?
The requirements in this case are being able to access the members. I.e. in code you don’t write a unintelligible 0, but FieldAssociations.FIELD_ASSOCIATION_POINTS (though FieldAssociations.POINTS would be better, but that’s another issue).
It’s probably reasonable for 3.4 to be the minimum.
When it comes to supported versions, I prefer to be pragmatic rather than dogmatic. There are supported linux distros out there that still use Python 3.4. For example, Debian Jessie still has a few more months before it EOLs, and RHEL 7 has several years. RHEL 7 in particular is used in lots of HPC systems, and HPC is a significant part of the VTK user base.
When it comes to deciding which versions of Python to support, it’s best to balance these considerations:
Ah right, thanks that works indeed. I didn’t expect those to be package globals but members of FieldAssociations, which lead me to misinterpret the docs. We will likely still create an actual enum FieldAssociations such that: FieldAssociations.POINTS == vtk.vtkDataObject.FIELD_ASSOCIATION_POINTS. That just feels more pythonic (aka less surprising), but that makes my use case even more just “nice-to-have”.