ink it 
is not unlikely that you *are* the only ones affected by it.

With "in the wild" I'm referring to the function being released in
the ccompiler not only in alpha releases but also in the beta
releases, the 2.7, 2.7.1 and 2.7.2 release - in every release
since early in 2010.

We were unaware of the reversal of the changes by Tarek and
the way we coded things in mxSetup.py did not show that things
were removed again, simply because we support more than just
Python 2.7 and have proper fallback solutions for most things.

Only in this particular case, we were using different strategies
based on the Python version number and so there is no fallback.

> Nevertheless, what are the alternatives?  We could add a wrapper function into distutils.ccompiler that just calls the distutils.sysconfig version.  Here's a patch that attempts to do so. That should fix that breakage for the eGenix packages.  It would be great if you could test it.

The fix is easy: simply import the customize_compiler() API in
the ccompiler module to maintain compatibility with what had
already been release. No need to add a wrapper function,
a single

from distutils.sysconfig import customize_compiler()

in ccompile.py will do just fine.

> It's up to the 2.7 release manager to decide what action to take, i.e. whether the patch is needed and, if so, how quickly to schedule a new release.  As a practical matter, regardless of whether the patch is applied in Python or not, I would assume that a faster solution for your end users would be to ship a version of the eGenix packages that reverts the changes(s) there.  By the way, it looks like you'll need to eventually do that anyway since the code in mxSetup.py incorrectly assumes that the corresponding changes were also made to Python 3.2.

We don't support Python 3.x yet, so that's a non-issue at the moment.

But yes, we will have to release new patch level releases for all
our packages to get this fixed for our users.