Added support for cpdef enum (take 2) #232

wants to merge 1 commit into


None yet
2 participants

nnemkin commented May 22, 2013

This is a resurrection of PR45.

I've started with @vitek's patch, fixed .pxd enum processing and added more tests.

To answer comments in the original thread:

  • Enums as Python classes is a completely different feature. cpdef enum simply exposes C enumeration values, which are always module scoped.
    Therefore, modname.VALUE_NAME has the same meaning in Cython (C level) and Python.
  • Cython type system and its handling of enum types is not affected in any way.

My use case: I have two modules full of numeric constants (~500 in total) that are used throughout the project. Currently it is impossible to expose them to Python without duplicating every definition. Also, it is impossible to declare Python values in the same module as C enum values, due to name conflict. (I have considered using globals().extend(VALUE=..., etc) but opted for this patch instead.)

Docs will be written if/when the change is approved.

Would "from enum cimport *" reexport the enums?

I'm just wondering how users can control in which cases an enum appears in the API and when it doesn't. I think this should be visible in the tests and also be documented explicitly.

I also think that I would be happier with a solution that allowed re-exporting the enums even when they are declared as a simple "cdef enum". Having to copy the declaration just because someone else didn't declare it "cpdef" is just as bad as what we currently have.


nnemkin replied Jun 9, 2013

I've just checked and this implementation does materialize cimported enums, although it should not!
cpdef enum should only be materialized in its own module (meaning that cpdef enum in a .pxd file makes no sense without a corresponding .pyx file.)

Exposing external enums to Python is a common problem, but cpdef enums do not not aim to solve it. Their behavior and usage is consistent with cpdef functions (after I fix reexport bug) and, given the simplicity of implementation, I think their existence is justified.

Arbitraty enum reexport ("materialization") will require new syntax and new semantics, which ups the complexity quite a bit. Language design is never easy.
Actually, I see automatic materialization of C declarations as the domain of wrapper generators. If enums become automated, why not functions and structs? Some lightweight wrappers are 99% python-to-c call bolierplate.
I don't mind Cython building such features into the language, but it requires considerable design and implementation effort. When viewed from this angle, materialization is not related to cpdef enums at all. Sure, there are tehcnical similarities, but semantic difference is huge.


nnemkin replied Jun 11, 2013

BTW, for reasons unknown to me, in-modue enums are materialized when they are declared public. cpdef enum can be seen as a variant of this functionality.

@scoder scoder referenced this pull request Jul 11, 2014


Add support for cpdef enum #45


scoder commented Jul 11, 2014

Superseded by ef9c1c3

@scoder scoder closed this Jul 11, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment