Which C compiler?

[Jive Dadson]

I am using Python 2.4. I need to make a native Python extension for
Windows XP. I have both VC++ 6.0 and Visual C++ 2005 Express Edition.
Will VC++ 6.0 do the trick? That would be easier for me, because the
project is written for that one. If not, will the 2005 compiler do it?

Thanks much,
"Jive"

 

[Jive Dadson]

P.s. I just found out that there's a new Express edition, 2008. (New to
me, that is.) I'm installing it.

 

[Martin v. Löwis]

I am using Python 2.4. I need to make a native Python extension for
Windows XP. I have both VC++ 6.0 and Visual C++ 2005 Express Edition.
Will VC++ 6.0 do the trick? That would be easier for me, because the
project is written for that one. If not, will the 2005 compiler do it?

In general, to build extension modules, you need to use the same VC
version as the one that was used to build Python. For 2.4, that would
be Visual Studio 2003. So if you use VC 6, VS 2005, or VS 2008, you
may run into problems.

Depending on what exactly the extension module does, it might work
fine also.

Regards,
Martin

 

[Jive Dadson]

In general, to build extension modules, you need to use the same VC
version as the one that was used to build Python. For 2.4, that would
be Visual Studio 2003. So if you use VC 6, VS 2005, or VS 2008, you
may run into problems.

Depending on what exactly the extension module does, it might work
fine also.

Regards,
Martin

Thanks. I think I might just use some variety of Popen instead. I
don't need much communication between the C++ application and Python,
and it's not time-critical. I cannot get flush() to work on the Python
side of the pipe however I try. That seems to be a common complaint.
But I can work around it.

I love Python, but the update regimen is very frustrating. It's a
misery to me why every major release requires new versions of so much
application stuff. No other software that I use is like that. When I
upgrade Windoze, I do not have to get new matching versions of all my
editors, browsers, and whatnot. But Python makes me do that, and that's
why I am stuck on release 2.4. Even the pure Python stuff needs to be
copied from one "site-packages" to another. Then I have to figure out
why it won't work. I have fought my way through the upgrade path twice,
and I just can't face it again.

Thus endeth the rant.

 

[Emile van Sebille]

On 5/18/2009 1:27 PM Jive Dadson said...

I love Python, but the update regimen is very frustrating. It's a
misery to me why every major release requires new versions of so much
application stuff. No other software that I use is like that. When I
upgrade Windoze, I do not have to get new matching versions of all my
editors, browsers, and whatnot. But Python makes me do that, and that's
why I am stuck on release 2.4. Even the pure Python stuff needs to be
copied from one "site-packages" to another. Then I have to figure out
why it won't work. I have fought my way through the upgrade path twice,
and I just can't face it again.

Thus endeth the rant.

Hmm.. I support python versions ranging from 1.52 though 2.6 on some
40-50 production systems and don't have an issue with upgrades. First,
once I stabilize a production system it doesn't get upgrades anymore
unless the machine breaks or the application specs change to the point
where upgrade is better than maintaining. Second, when setting up a new
system I always start with the freshest versions of things (barring
python 3.x which I haven't yet put in a production environment).

Upgrading because newer is available has been a problem as long as
upgrades have been available. Just this month some system snuck by me
with windows update enabled only to have microsofts auto-update break
the applications.

Just say no to updates...

Emile

 

[norseman]

Thanks. I think I might just use some variety of Popen instead. I
don't need much communication between the C++ application and Python,
and it's not time-critical. I cannot get flush() to work on the Python
side of the pipe however I try. That seems to be a common complaint.
But I can work around it.

I love Python, but the update regimen is very frustrating. It's a
misery to me why every major release requires new versions of so much
application stuff. No other software that I use is like that. When I
upgrade Windoze, I do not have to get new matching versions of all my
editors, browsers, and whatnot. But Python makes me do that, and that's
why I am stuck on release 2.4. Even the pure Python stuff needs to be
copied from one "site-packages" to another. Then I have to figure out
why it won't work. I have fought my way through the upgrade path twice,
and I just can't face it again.

Thus endeth the rant.

==============================
I suspect that if all python users were in the same room and the
question "Are you NOT happy with python's upgrade requirements?" was
asked you would find most hands in the air. I have said it before - the
current attitude of 'new means we start over' was what nearly destroyed
Apple. Doesn't take joe public long to get tired of constantly
re-buying, re-writing themselves, re-hiring the same people to re-write
the same thing, etc... Most people who do programming are not for hire.
They are the ones that write for their discipline to make their routine
chores easier and less typo/error prone and thus (hopefully) have more
take home money with less effort at the end of the day. I bump heads
with version problems daily and it does not make me happy either. Can
anyone give a valid excuse for not having a "new version" widget getting
a new name? Say os25.popen os26.popen os30.popen
pylib25 pylib26 pylib30
Sorry, but "Because we had to change (...) to make it work with (...)"
is NOT a valid excuse for ripping the whole thing apart. At the end of
the day (the program run), the data is still the data. It probably is
still going to the same form it's always been converted into. The form
that the boo-koo dollars proprietary package demands. In short, while
Python is a good idea and can do a great job acting standalone in some
cases and as well as the glue between things, it is not an end unto
itself. It's just another tool. Tools that keep breaking get tossed
into the trash can and the vendor that makes them gets bad mouthed to
everyone who will listen.
That is reality.



Steve

 

[norseman]

On 5/18/2009 1:27 PM Jive Dadson said...

Hmm.. I support python versions ranging from 1.52 though 2.6 on some
40-50 production systems and don't have an issue with upgrades. First,
once I stabilize a production system it doesn't get upgrades anymore

this is where the guy chides: cheat, cheat see below

unless the machine breaks or the application specs change to the point
where upgrade is better than maintaining. Second, when setting up a new
system I always start with the freshest versions of things (barring
python 3.x which I haven't yet put in a production environment).

Upgrading because newer is available has been a problem as long as
upgrades have been available. Just this month some system snuck by me
with windows update enabled only to have microsofts auto-update break
the applications.

Just say no to updates...

Welcome to the club!

Emile

You-all have a great day now! - ya here?

Steve

 

[Jorgen Grahn]

I suspect that if all python users were in the same room and the
question "Are you NOT happy with python's upgrade requirements?" was
asked you would find most hands in the air. I have said it before - the
current attitude of 'new means we start over' was what nearly destroyed
Apple. Doesn't take joe public long to get tired of constantly
re-buying, re-writing themselves, re-hiring the same people to re-write
the same thing, etc...

I dislike the "bleeding edge" aspect of Python culture too, but (as
long as everyone ignores Python 3.0) it's not really something which
hurts me in my daily life. *Not* using Python would hurt, though.

I'm on Linux though, and use no third-party modules which haven't
already been filtered by Debian's maintainers. I don't know if that's
the reason, but my applications rarely or never break. So I'm not
quite sure what happened in your case ...

/Jorgen

 

[norseman]

I dislike the "bleeding edge" aspect of Python culture too, but (as
long as everyone ignores Python 3.0) it's not really something which
hurts me in my daily life. *Not* using Python would hurt, though.

agreed! emphatically so

I'm on Linux though, and use no third-party modules which haven't
already been filtered by Debian's maintainers. I don't know if that's
the reason, but my applications rarely or never break. So I'm not
quite sure what happened in your case ...

Linux, me too. MY apps, same. Coupling to vendor apps - busted.

/Jorgen

I cannot speak for the OP, but I have run into version problems as a
result of dealing with purchased applications that use python as the (or
one of the allowed) scripting languages for user written tweaks. As an
example I'll use fictitious Company-One that released 9.1 which had no
python. Then they released 9.2 which came with python 2.4 and then they
released 9.3 which came with python 2.5(.1) plus the other languages
like VBA that have been there all along. A program NOT using Company-One
hooks but rather just the python itself (as in a small scientific
calculator for use 'on the side') which was written in 2.4 will not run
on 2.5. Who knows why. (The first error noted had to do with version
miss-match.) It's these types of inconsistencies that are annoying.
Since the place I work converted to Company-One's 9.3 and someone fixed
the calculator to run on 2.5, I left the research into what might be the
actual problem in a file somewhere. I believe it was a circular file.
I have my own calculator so I don't use the other one anyway.

That scenario is probably the norm for most companies with more than one
individual in them who use purchased applications and write in-house
'scripts'. The lack of upward compatibility is always annoying.

In all fairness to Python, it is not nearly as bad as VBA when it comes
to breaking. VBA quits when the OS version changes, when the VBA
version changes, when the VB6 version changes. It also seems to break
each time sneeze. Whereas when a given version of Python is loaded
on both Linux and Windows I can samba a drive and use the same single
one and only one file on both OSs at the same time if I wish, with the
same certainty. All except the fonts. Three different Window machines
all running the same OS release/patches and I get three different
results for the same mono spaced font. Go figure.



Steve