New versions breaking extensions, etc.

[Jive]

"Nick Coghlan" <ncoghlan at iinet.net.au> wrote in message
news:mailman.7514.1102742911.5135.python-list at python.org...
> Jive wrote:
> > Can someone explain to me why Python 2.4 on MS Windows has these
backward
> > compatibility problems?  What am I missing?
>
> The problem is the Python C/API. At the moment, it exposes things directly
(like
> data structures) that may change size between major version releases.

Okay.  That could be fixed.

> The other
> issue is that the interpreter and the extensions may be linked to
different
> versions of the Microsoft runtime.

Doesn't Microsoft have an answer for that?  There are (at last count) nine
skillion ActiveX
components in the wild.  Surely Microsoft didn't blast them into oblivion
with dot-net -- did it?

>
> This is a solvable problem, but it would require:
>    1. Major additions to the C/API - a "Python Major Version Agnostic" API
that
> hides all data structures behind opaque pointers, never passes file
descriptors
> between the interpreter and the extension and never gets Python to delete
memory
> allocated by the extension (or vice-versa)

I remember having trouble with that last bit once.  But I seem to recall
there was an easy
answer.  Something to do with the main ap and the DLL using the same heap or
some
such thing.

>    2. Rewriting extensions to use the new API functions instead of the
current
> major version specific ones.

That's a one-time thing, for those who choose to do it.  Certainly the old
API
would still be available.

>
> Such an API is likely to be both harder to work with and slower, simply
due to
> the limitations of C.
>
> To this date, no-one has cared enough about the problem to put in the
effort
> required to make the C API version agnostic. Given that the API almost
always
> remains *source* compatible, within a month or two of a new Python
release, the
> extension developers have generally tweaked their build environments to
also
> produce binaries for the new release.

It would be a Good Thing to put a stop to that requirement, no?

>
> In the current case (Python 2.4), the transition from msvcrt to msvcrt71,
and
> the poor quality of the free development tools offered by Microsoft has
> exacerbated the problem on Windows.

No doubt.  I don't understand what the deal is with msvcr71 and all that,
but I have
figured out that it's a dirty rotten shame.  If you google for msvcr71, you
will
get pages and pages of links to plaintive cries for help.  We are not alone.

> The Python developers are looking at
> improving the documentation and support for building extensions with
Windows
> compilers other than Visual Studio .Net 2003 (mainly MinGW and the free MS
tools).
>

That would be good.   But is using VC++ 6.0 right out?  As it stands, I can
no longer
build extensions that will run with a standard dot-net Python 2.4 release.
Or at least I don't
know how.  And if I build 2.4 under VC++ 6.0 and distribute that around the
company, it's not
clear to me if  we can then use new third party extensions.  Some
documentation
clearing it all up would be very helpful.  Maybe it exists somewhere
already.  This is
a Microsoft problem, not a Python problem.

Like I said, dirty rotten shame.

Thinking it over, I'm wondering why the Python crowd went with dot-NET in
the first place.
Surely the world would be a better, happier place without MS jerking
everyone around.
We work our fingerprints to the bone writing code to make their stinking
little OS do something
useful, and what have they ever given us in return? -- Besides the
aquaducts?

Jive