FAQ
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"

Search Discussions

  • Jive Dadson at May 18, 2009 at 5:27 am
    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 at May 18, 2009 at 7:07 am

    Jive Dadson wrote:
    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 at May 18, 2009 at 8:27 pm

    Martin v. L?wis wrote:
    Jive Dadson wrote:
    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
    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 at May 18, 2009 at 9:53 pm
    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 at May 18, 2009 at 11:06 pm

    Emile van Sebille wrote:
    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
    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
  • Norseman at May 18, 2009 at 10:47 pm

    Jive Dadson wrote:
    Martin v. L?wis wrote:
    Jive Dadson wrote:
    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
    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
  • Jorgen Grahn at May 19, 2009 at 4:00 pm

    On Mon, 18 May 2009 15:47:41 -0700, norseman wrote:

    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

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
  • Norseman at May 19, 2009 at 5:02 pm

    Jorgen Grahn wrote:
    On Mon, 18 May 2009 15:47:41 -0700, norseman wrote:

    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.
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedMay 18, '09 at 5:18a
activeMay 19, '09 at 5:02p
posts9
users5
websitepython.org

People

Translate

site design / logo © 2022 Grokbase