Wrap enums as python's enum.Enum

I just reviewed a PR where a python project uses the FieldAssociation enum and had to re-create enum vtkDataObject::FieldAssociations, because the wrapped type isn’t actually a python enum (as in https://docs.python.org/3/library/enum.html).

  1. I wrapping enums as python’s enum.Enum planned?
  2. If not, do you agree that such a think would be beneficial?

@dgobbi

Note that enum is new in 3.4 , so this may affect our minimum supported Python3 version without conditionals.

I believe that should be fairly unproblematic, as python 3.3 reached end of life quite a while ago (https://www.python.org/dev/peps/pep-0398/#lifespan), 3.4 too for that matter (https://devguide.python.org/#status-of-python-branches).

Where are supported Python versions documented? I wasn’t able to find anything on that.

I think we still have a 3.2 dashboard around. I’m personally fine with bumping it, but I think @seanm and @dgobbi are usually the ones asking to keep the minimum lower.

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:

  1. What versions are people using?
  2. How onerous is it to support each version?

But the mnemonics have always been there, I’ve been using them for at least a decade.

> python -c 'import vtk ; print(vtk.vtkDataObject.FIELD_ASSOCIATION_POINTS)'
0

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”.

Without checking, I’m pretty sure they are class members and mirror the C++ usage:

vtkDataObject::FIELD_ASSOCIATION_POINTS // C++
vtkDataObject.FIELD_ASSOCIATION_POINTS # Python

Makes it very easy to translate examples…

Mmmh, forgot about the plain enum vs enum class distinction in C++ - and this is indeed a plain enum, thus the members are part of the class namespace. Sorry for the noise and thanks for your help.

I imagine most of these are still Python2, so bumping the minimum Python3 probably isn’t much of a big deal. But yes, 3.4 sounds reasonable.

I do too (for VTK :slight_smile: ). But it has been a few years since I think the question has been asked (when we were setting up initial Python3 buildbots seems about right).

However, the initial feature sounds reasonable anyways. We can at least file an issue for it.

1 Like