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

[M.-A. Lemburg]

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/