# Wrap enums as python's enum.Enum
**URL:** https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909
**Category:** Development
**Created:** [March 29, 2020, 11:10am UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909 "2020-03-29T11:10:54Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@imsodin](https://discourse.vtk.org/u/imsodin)
#### Post date: [March 29, 2020, 11:10am UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/1 "2020-03-29T11:10:54Z")
I just reviewed a PR where a python project uses the `FieldAssociation` enum and had to re-create [enum vtkDataObject::FieldAssociations](https://vtk.org/doc/nightly/html/classvtkDataObject.html#a54fdf8345a01c89e618feca3c10002b1), because the wrapped type isn’t actually a python enum (as in [https://docs.python.org/3/library/enum.html](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?
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 29, 2020, 5:06pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/2 "2020-03-29T17:06:43Z")
@dgobbi
Note that `enum` is new in 3.4 , so this may affect our minimum supported Python3 version without conditionals.
---
### Author:  [@imsodin](https://discourse.vtk.org/u/imsodin)
#### Post date: [March 29, 2020, 5:28pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/3 "2020-03-29T17:28:45Z")
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](https://www.python.org/dev/peps/pep-0398/#lifespan)), 3.4 too for that matter ([https://devguide.python.org/#status-of-python-branches](https://devguide.python.org/#status-of-python-branches)).
Where are supported Python versions documented? I wasn’t able to find anything on that.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 29, 2020, 6:15pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/4 "2020-03-29T18:15:18Z")
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.
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [March 29, 2020, 6:18pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/5 "2020-03-29T18:18:28Z")
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?
---
### Author:  [@imsodin](https://discourse.vtk.org/u/imsodin)
#### Post date: [March 29, 2020, 6:38pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/6 "2020-03-29T18:38:56Z")
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).
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [March 29, 2020, 6:48pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/7 "2020-03-29T18:48:20Z")
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?
---
### Author:  [@efahl](https://discourse.vtk.org/u/efahl)
#### Post date: [March 29, 2020, 6:59pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/8 "2020-03-29T18:59:44Z")
But the mnemonics have always been there, I’ve been using them for at least a decade.
```auto
> python -c 'import vtk ; print(vtk.vtkDataObject.FIELD_ASSOCIATION_POINTS)'
0
```
---
### Author:  [@imsodin](https://discourse.vtk.org/u/imsodin)
#### Post date: [March 29, 2020, 7:09pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/9 "2020-03-29T19:09:33Z")
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”.
---
### Author:  [@efahl](https://discourse.vtk.org/u/efahl)
#### Post date: [March 29, 2020, 7:20pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/10 "2020-03-29T19:20:30Z")
Without checking, I’m pretty sure they are class members and mirror the C++ usage:
```auto
vtkDataObject::FIELD_ASSOCIATION_POINTS // C++
vtkDataObject.FIELD_ASSOCIATION_POINTS # Python
```
Makes it very easy to translate examples…
---
### Author:  [@imsodin](https://discourse.vtk.org/u/imsodin)
#### Post date: [March 29, 2020, 7:23pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/11 "2020-03-29T19:23:46Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [March 29, 2020, 7:33pm UTC](https://discourse.vtk.org/t/wrap-enums-as-pythons-enum-enum/2909/12 "2020-03-29T19:33:28Z")
> [@dgobbi](#):
>
> 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.
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.
> [@dgobbi](#):
>
> When it comes to supported versions, I prefer to be pragmatic rather than dogmatic.
I do too (for VTK 🙂 ). 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.