[Python-Dev] On track for Python 2.6.4 final this Sunday?

P.J. Eby wrote: > At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote: >> Are we on track to release 2.6.4 final this Sunday or do we need >> another rc? >> >> Yesterday, Tarek committed another setuptools related fix and said >> that he was going to run a bunch of build tests locally. Tarek, how >> did that go? > > FWIW, that change won't work to fix the problem on Windows if a > package's setup.py is written with cross-platform paths (i.e., the usual > case). > > Also, for the record, it's not really a setuptools-related fix; it's > just attempting to fix collateral damage caused by the attempt to fix > the problems caused by the original API change... which affected all > build_ext customizations relying on the docstring of the changed method, > not just the one in setuptools. Just to clarify a bit what all the fuzz is about: The API in question (build_ext.get_ext_filename()) was not changed at all. The doc-string also doesn't refer to *the* extension currently being built, but to just to some arbitrary extension: def get_ext_filename (self, ext_name): r"""Convert the name of an extension (eg. "foo.bar") into the name Convert the name of an extension (eg. "foo.bar") into the name of the file from which it will be loaded (eg. "foo/bar.so", or "foo\bar.pyd").""" What did change is the way this method is used by other methods in build_ext: the method is no longer being called with the full dotted name, but only with the last component. Now, setuptools and pywin32 both override the method, with the understanding that this method is the one and only way to convert the extensions (full) dotted name into a file name. Up until the change (which was needed to get inplace installations working), that assumption was true. However, neither the doc-string nor the implementation of the method ever implied this. distutils occasionally makes such assumptions necessary since there's no clean OO-way to override the functionality. That's not ideal, but works most of the time. However, authors of distutils add-ons cannot really expect such hacks to survive forever. Rather than relying on these, it's better to get distutils fixed to provide the necessary OO-hooks to properly implement the modified functionality. FWIW, I've had to change and tweak our mxSetup.py many many times to get it to work again with new distutils releases and I expect this to occur even more often now that distutils is finally being maintained again - and that's good, since I'll be able to get rid off the few remaining hacks ! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/