Yes, putting implementation-specific environment markers in the Extensions section is the idea (instead of the haphazard and occasionally-applied 'Python code in setup.py appends to a list of extensions' method).

An Extension can only be optional when there is equivalent and working Python code. This isn't likely to happen for libraries like PIL where the foreign code provides core functionality instead of a speedup.

The reason I submitted this bug is that as Pypy's C API improves it can successfully compile Extensions to its detriment. Unlike Jython which IIRC has no C API, Pypy cannot patch Extension to always fail, but some of those Extensions are slower than the equivalent Python.

I think there ought to be a declarative way to mark an extension as

a. Required
b. Optional and preferred
c. Optional, not preferred

depending on the Python implementation. For (b) and (c) it would also be quite cool to have a standard flag or runtime mechanism to switch between the C and Python implementation to see which one was really faster (could be done with an import hook?).