New versions breaking extensions, etc.

[Jive]

Can someone explain to me why Python 2.4 on MS Windows has these backward
compatibility problems? What am I missing? Why won't extensions compiled
to run with 2.3 also work with 2.4? Why does it matter whether a component
was compiled with VC++ 6.0 or 7.1? I've been using MS stuff for 6 years.
Before I started using Python, I don't remember ever having a program tell
me I had to use an OLDER version of something to make the program work.
Newer, maybe, but older, never. I had to revert to Python 2.3 because I
have applications that will not run under Python 2.4.

Although I have been a full-time software developer since the late 70's, I
don't know much about Microsoft stuff. (Amazing trick that, eh?) But I've
been reading some things on the MS web pages that say dot-NET and all that
should NOT break existing stuff.
http://msdn.microsoft.com/library/en..._libraries.asp I
don't pretend to understand it all, but certainly one would not expect MS to
screw things up too badly on purpose. The value of MS Windows lies in the
applications that it can run. That's part of the genius of the Evil Genius.
He understood when others didn't that when Joe Blow in his basement develops
a program to run under MS Windows, Joe Blow is making money for the E.G.,
and it doesn't cost the E.G. a penny.

In my own small domain, I cannot even consider coming out with new releases
that are not drop-in replacements for what went before. Customers won't go
for it. It's an absolute deal-breaker.

What puzzles me is that, apparently, the incompatibility of Python 2.4 and
extensions built for 2.3 did not come as a nasty surprise. I get the
impression that it was expected. Can someone explain that to me?

I hope this doesn't sound like I'm complaining. I think Python is great.
And the price can't be beat!

[Jive]

"Martin v. Löwis" <ma****@v.loewi s.de> wrote in message
news:41******** ******@v.loewis .de...

OTOH, people who only have VC6 just need to buy VS.NET 2003,
which is still available.

I don't even know how to do that! :-) What's the difference between VC++
..net Standard and Visual Studio .net Pro? (Besides $370?) Is the former
C++ only, but with the IDE, and the later the whole shebang with SourceSafe,
VBASIC, and all that?

OH NO! I've gone seriously off-topic. Please don't call the Spanish
Inquisiton. Allow me to re-phrase the question: What do I need to build
(on-topic) Python extensions?

[John Machin]

Jive wrote:

"Martin v. Löwis" <ma****@v.loewi s.de> wrote in message
news:41******** ******@v.loewis .de...

OTOH, people who only have VC6 just need to buy VS.NET 2003,
which is still available.
I don't even know how to do that! :-) What's the difference between

VC++ .net Standard and Visual Studio .net Pro? (Besides $370?) Is the former C++ only, but with the IDE, and the later the whole shebang with SourceSafe, VBASIC, and all that?

OH NO! I've gone seriously off-topic. Please don't call the Spanish
Inquisiton. Allow me to re-phrase the question: What do I need to build (on-topic) Python extensions?

Short answer to Jive's question: (1) free non-MS C compiler (either
MinGW or Borland) (2) inner calm.

I really can't understand what all the screaming and yelling is about.
Windows Python is built using an MS compiler. Those extension
developers who can't/won't buy the MS compiler use either the free
MinGW compiler or the free Borland 5.5 compiler (or both!). Yes, you
have to be careful about mixing the runtimes. An extension that tries
to use a FILE * that was created by Python will crash. Using free() on
a pointer that was malloc()ed by the other party isn't a bright idea
either. There are adequate solutions to these problems, involving
Python-supplied higher-level functions instead of C runtime functions.
Otherwise, not a problem. Distutils has made the process of using MinGW
and bcpp a snap. The documentation is adequate. When a new version of
Python comes out, one rebuilds and tests one's extensions. So ... now
there are THREE compilers that can be used instead of the one that
Python's built with; what's the big deal?

[It's me]

On the other hand, it can be annoying.

I can't use Python 2.4 right now because NumPy won't run. So, I need to
wait for NumPy to get updated.

Of course, one would say: but NumPy is open source, go build it yourself.

My answer is simple: If there are more then 24 hours to a day, I definitely
would...

--
It's me
"John Machin" <sj******@lexic on.net> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .
Jive wrote:

"Martin v. Löwis" <ma****@v.loewi s.de> wrote in message
news:41******** ******@v.loewis .de...

OTOH, people who only have VC6 just need to buy VS.NET 2003,
which is still available.
I don't even know how to do that! :-) What's the difference between

VC++ .net Standard and Visual Studio .net Pro? (Besides $370?) Is the former C++ only, but with the IDE, and the later the whole shebang with SourceSafe, VBASIC, and all that?

OH NO! I've gone seriously off-topic. Please don't call the Spanish
Inquisiton. Allow me to re-phrase the question: What do I need to build (on-topic) Python extensions?

Short answer to Jive's question: (1) free non-MS C compiler (either
MinGW or Borland) (2) inner calm.

I really can't understand what all the screaming and yelling is about.
Windows Python is built using an MS compiler. Those extension
developers who can't/won't buy the MS compiler use either the free
MinGW compiler or the free Borland 5.5 compiler (or both!). Yes, you
have to be careful about mixing the runtimes. An extension that tries
to use a FILE * that was created by Python will crash. Using free() on
a pointer that was malloc()ed by the other party isn't a bright idea
either. There are adequate solutions to these problems, involving
Python-supplied higher-level functions instead of C runtime functions.
Otherwise, not a problem. Distutils has made the process of using MinGW
and bcpp a snap. The documentation is adequate. When a new version of
Python comes out, one rebuilds and tests one's extensions. So ... now
there are THREE compilers that can be used instead of the one that
Python's built with; what's the big deal?

[Steven Bethard]

It's me wrote:

My answer is simple: If there are more then 24 hours to a day, I definitely
would...

Can we get a patch in for this?

datetime.timede lta(hours=24) + datetime.timede lta(hours=1) datetime.timede lta(1)

would be much preferable to the current:
datetime.timede lta(hours=24) + datetime.timede lta(hours=1)

datetime.timede lta(1, 3600)

;)

Steve

[Jeremy Bowers]

On Sat, 11 Dec 2004 01:28:45 -0600, Mike Meyer wrote:

Actually, there's a problem on Unix that may not exist on
Windows. Python is installed in <PREFIX>/lib/python<version>/. This
lets us have multiple versions of Python installed at the same time,
which is a good thing.
...
The real solution is...

Interestingly, I saw you going somewhere else for this. I expected,

"The real solution is, at least for the pure Python packages, a
system-wide directory for those, reserving site-packages for things that
are truly version specific."

I'm not sure I'm ready to "propose" this yet, but thoughts? Bad idea, good
idea?

Obviously it isn't perfect, but it seems to me that reverse compatibility
has been good enough for a while now that the imperfections are minor in
impact...

[Martin v. Löwis]

Jive wrote:

I don't even know how to do that! :-) What's the difference between VC++
.net Standard and Visual Studio .net Pro? (Besides $370?) Is the former
C++ only, but with the IDE, and the later the whole shebang with SourceSafe,
VBASIC, and all that?
According to

http://msdn.microsoft.com/howtobuy/vstudio/

there is, for VS.NET, "Academic", "Profession al", "Enterprise
Developer", and "Enterprise Architect". For Python extensions, all
these releases will work; see

http://msdn.microsoft.com/howtobuy/vstudio/features/

for a checkmark list. For VC++ .NET 2003 Standard, it appears that
you get just the C++ compiler, and the IDE, see

http://msdn.microsoft.com/howtobuy/v...s/default.aspx
OH NO! I've gone seriously off-topic. Please don't call the Spanish
Inquisiton. Allow me to re-phrase the question: What do I need to build
(on-topic) Python extensions?

Either VS.NET 2003 or VC++ .NET 2003 should do (although I don't know
anybody who owns the latter to be sure). The core issue is that it needs
a "native" C++ compiler (ie. not just managed C++), and that it needs
mscvcr71.dll.

Regards,
Martin

[Jive]

"Martin v. Löwis" <ma****@v.loewi s.de> wrote in message
news:41******** ****@v.loewis.d e...

Either VS.NET 2003 or VC++ .NET 2003 should do (although I don't know
anybody who owns the latter to be sure). The core issue is that it needs
a "native" C++ compiler (ie. not just managed C++), and that it needs
mscvcr71.dll.

Sorry if I'm being dense. If I had that DLL, why couldn't I use VC++ 6.0?

It's still not clear to me exactly what's in each package. One would think
there would be a more technical description on the MS web pages.

[Martin v. Löwis]

Jive wrote:

Either VS.NET 2003 or VC++ .NET 2003 should do (although I don't know
anybody who owns the latter to be sure). The core issue is that it needs
a "native" C++ compiler (ie. not just managed C++), and that it needs
mscvcr71.dl l.

Sorry if I'm being dense. If I had that DLL, why couldn't I use VC++ 6.0?

Sorry for being imprecise. You don't need just msvcr71.dll, you need an
import library for it, and you need to cause link.exe to use that import
library. VC6 will continue to link your extension modules with
msvcrt40.dll - regardless of what other DLLs you have on your system.

It might be that you also need the header files for msvcr71.dll,
although I believe you could get away with using the "wrong" (i.e.
VC6) header files.

Regards,
Martin

[Jive]

"Martin v. Löwis" <ma****@v.loewi s.de> wrote in message
news:41******** *************** @news.freenet.d e...

Jive wrote:

Either VS.NET 2003 or VC++ .NET 2003 should do (although I don't know
anybody who owns the latter to be sure). The core issue is that it needs
a "native" C++ compiler (ie. not just managed C++), and that it needs
mscvcr71.dl l.
Sorry if I'm being dense. If I had that DLL, why couldn't I use VC++

6.0?
Sorry for being imprecise. You don't need just msvcr71.dll, you need an
import library for it, and you need to cause link.exe to use that import
library. VC6 will continue to link your extension modules with
msvcrt40.dll - regardless of what other DLLs you have on your system.

It might be that you also need the header files for msvcr71.dll,
although I believe you could get away with using the "wrong" (i.e.
VC6) header files.

Regards,
Martin

Well, ain't that enough to gag a maggot? I was aware that DLL's don't
really link dynamically. I was not aware that the crt dll file name was
hard-coded into the linker. But I looked on the link line and, sure enough,
that particular dll was not listed among the others.

Malice or incompetence? You be the judge.

[Martin v. Löwis]

Jive wrote:

Well, ain't that enough to gag a maggot? I was aware that DLL's don't
really link dynamically. I was not aware that the crt dll file name was
hard-coded into the linker. But I looked on the link line and, sure enough,
that particular dll was not listed among the others.

It's not hard-coded in the linker, but hard-coded in the import library.
So if you link with msvcrt.lib (which might not be the precise name
of the import library - I cannot look up the precise name right now),
msvcrt.lib will in turn refer to msvcr71.dll.

In addition, through #pragma comment(lib, foo.lib), the Microsoft C
*header* files force references to import libraries into the object
files, so that the import libraries don't even appear on the linker
line - instead, the linker gets additional command line options from
the object files; use dumpbin to find out what those are.

On the plus side, I believe that the name of the import library for
the CRT was always the same (msvcrt.lib), so different versions of
that file refer to different actual CRTs (msvcrt.dll, msvcrt40.dll,
msvcr70.dll, msvcr71.dll). So just replacing your msvcrt.lib file
of VC6 with the VC71 one might be enough - but then, perhaps there
also where changes to the header files which you need to get.

Regards,
Martin