"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 -- http://mail.python.org/mailman/listinfo/python-list
