Re: Help embedding python

Discussion in 'Python' started by Peter Hansen, Aug 25, 2003.

  1. Peter Hansen

    Peter Hansen Guest

    Zora Honey wrote:
    >
    > My husband and I are writing a program that does a lot of math behind
    > the scenes (c++) with a gui front (python/Tkinter). We've decided that
    > we want the c++ to be the "driver", and so we want to embed the python.


    It's a little unclear (to me) exactly what you're trying to do,
    but in any case I can't imagine why you'd want to have C++ "drive"
    the Python code (if that's what you meant by "driver", as opposed to
    the more common sense as in "device driver") instead of the other
    way around.

    And my inability to imagine why you want this is compounded by your
    choice of Python and Tkinter for the front end. It is much more
    common to have the front end be the "driving" code, and the back end
    be "driven", especially in CPU-intensive applications as it sounds
    like you have here.

    -Peter
    Peter Hansen, Aug 25, 2003
    #1
    1. Advertising

  2. Peter Hansen

    Zora Honey Guest

    Peter Hansen wrote:
    > Zora Honey wrote:
    >
    >>Peter Hansen wrote:
    >>
    >>>Zora Honey wrote:
    >>>
    >>>
    >>>>My husband and I are writing a program that does a lot of math behind
    >>>>the scenes (c++) with a gui front (python/Tkinter). We've decided that
    >>>>we want the c++ to be the "driver", and so we want to embed the python.
    >>>
    >>>
    >>>It's a little unclear (to me) exactly what you're trying to do,
    >>>but in any case I can't imagine why you'd want to have C++ "drive"
    >>>the Python code (if that's what you meant by "driver", as opposed to
    >>>the more common sense as in "device driver") instead of the other
    >>>way around.
    >>>
    >>>And my inability to imagine why you want this is compounded by your
    >>>choice of Python and Tkinter for the front end. It is much more
    >>>common to have the front end be the "driving" code, and the back end
    >>>be "driven", especially in CPU-intensive applications as it sounds
    >>>like you have here.
    >>>
    >>>-Peter

    >>
    >>Okay. Let's assume that the choice to embed the python was a
    >>well-reasoned decision. Or assume that I want to embed some python for
    >>the pure joy of doing so. Can you help?

    >
    >
    > No, sorry. I have no particular expertise in embedding Python in a
    > C++ application in the way you wish.
    >
    > (If I did, and I had an easy answer, I would offer it. If, on the other hand,
    > I had no easy answer, and it was going to take some effort on my part,
    > I'd be happy to provide that effort if the person I was helping would
    > take a moment of his/her time to convince me that it was a well-reasoned
    > decision. If, on the other hand, the decision was based on ignorance
    > or merely on a frivolous desire to experience the joy of doing so at the
    > cost of another's valuable time, I would probably be less inclined to help...)
    >
    > (If you assume for a moment that the person who actually *can* help you
    > might feel somewhat the same way, you might take a moment to explain
    > the background rather than risk looking like you treat others' time as
    > less valuable than your own. It may not look that way to you, but I
    > was merely trying to help by showing you that at least one person was
    > puzzled by your choice. I'm also always interested in learning, so
    > I'd still be quite interested in your rationale, if you are willing to
    > provide it.)
    >
    > Cheers,
    > -Peter



    I'm sorry if I was a bit curt. The reason I didn't include rationale is
    because I have none. I have been advocating extending python instead of
    embedding it, but since I have no experience with either, my only
    argument is that it seems more natural. It seems like either method is
    as difficult to learn and implement. It doesn't seem to me that there
    are lot of arguments one way or the other. My husband, on the other
    hand, is strongly attached to the idea of having a c++ main program that
    will coordinate all the data-processing classes and python widgets. He
    believes it is easier to have c++ say to python, "here, I have these
    plots for you," rather than have python say to c++, "make these plots
    for me." I don't believe this is true, but I don't have any reason
    *not* to believe it's true, so I aquiesced.

    So, I suppose instead of asking you to assume the rationale are well
    reasoned, I should be asking you why you believe extending python is
    easier/cheaper/faster/better than embedding it.

    Thank you,
    Zora

    (who's hoping hubby isn't reading this newsgroup today)
    Zora Honey, Aug 25, 2003
    #2
    1. Advertising

  3. In article <>,
    Peter Hansen <> wrote:
    >Zora Honey wrote:
    >>
    >> Peter Hansen wrote:
    >> > Zora Honey wrote:
    >> >
    >> >>My husband and I are writing a program that does a lot of math behind
    >> >>the scenes (c++) with a gui front (python/Tkinter). We've decided that
    >> >>we want the c++ to be the "driver", and so we want to embed the python.
    >> >
    >> >
    >> > It's a little unclear (to me) exactly what you're trying to do,
    >> > but in any case I can't imagine why you'd want to have C++ "drive"
    >> > the Python code (if that's what you meant by "driver", as opposed to
    >> > the more common sense as in "device driver") instead of the other
    >> > way around.
    >> >
    >> > And my inability to imagine why you want this is compounded by your
    >> > choice of Python and Tkinter for the front end. It is much more
    >> > common to have the front end be the "driving" code, and the back end
    >> > be "driven", especially in CPU-intensive applications as it sounds
    >> > like you have here.
    >> >
    >> > -Peter

    >>
    >> Okay. Let's assume that the choice to embed the python was a
    >> well-reasoned decision. Or assume that I want to embed some python for
    >> the pure joy of doing so. Can you help?

    >
    >No, sorry. I have no particular expertise in embedding Python in a
    >C++ application in the way you wish.
    >
    >(If I did, and I had an easy answer, I would offer it. If, on the other hand,
    >I had no easy answer, and it was going to take some effort on my part,
    >I'd be happy to provide that effort if the person I was helping would
    >take a moment of his/her time to convince me that it was a well-reasoned
    >decision. If, on the other hand, the decision was based on ignorance
    >or merely on a frivolous desire to experience the joy of doing so at the
    >cost of another's valuable time, I would probably be less inclined to help...)
    >
    >(If you assume for a moment that the person who actually *can* help you
    >might feel somewhat the same way, you might take a moment to explain
    >the background rather than risk looking like you treat others' time as
    >less valuable than your own. It may not look that way to you, but I
    >was merely trying to help by showing you that at least one person was
    >puzzled by your choice. I'm also always interested in learning, so
    >I'd still be quite interested in your rationale, if you are willing to
    >provide it.)

    .
    .
    .
    Me, too.

    As usual, Peter writes for me. Perhaps it'll be useful to supplement
    his remarks, though.

    In general, Python's easy to embed; many, MANY people have found suc-
    cess with no or little more help than <URL: http://
    python.org/doc/current/ext/ext.html > affords.

    HOWEVER, I've never embedded Tkinter in that sense. Moreover, I can't
    think of a reason I'd want to start now. While I respect the clarity
    of your advice to "... assume the choice ...", my own experience has
    sooooooo much inclined me to favor extending over embedding (in the
    sense of this thread) that I feel no inclination to pursue what I
    understand you're describing.

    Let me summarize, again: there's abundant material on embedding Python;
    I know of none on embedding Tkinter (but wait; does John's book say
    anything on the subject? I don't have my copy at hand ...).
    --

    Cameron Laird <>
    Business: http://www.Phaseit.net
    Personal: http://phaseit.net/claird/home.html
    Cameron Laird, Aug 25, 2003
    #3
  4. In article <bidmuo$90l$>,
    Zora Honey <> wrote:
    .
    .
    .
    >I'm sorry if I was a bit curt. The reason I didn't include rationale is
    >because I have none. I have been advocating extending python instead of
    >embedding it, but since I have no experience with either, my only
    >argument is that it seems more natural. It seems like either method is
    >as difficult to learn and implement. It doesn't seem to me that there
    >are lot of arguments one way or the other. My husband, on the other
    >hand, is strongly attached to the idea of having a c++ main program that
    >will coordinate all the data-processing classes and python widgets. He
    >believes it is easier to have c++ say to python, "here, I have these
    >plots for you," rather than have python say to c++, "make these plots
    >for me." I don't believe this is true, but I don't have any reason
    >*not* to believe it's true, so I aquiesced.
    >
    >So, I suppose instead of asking you to assume the rationale are well
    >reasoned, I should be asking you why you believe extending python is
    >easier/cheaper/faster/better than embedding it.

    .
    .
    .
    Your husband's making a mistake--it's a plausible one, but a
    mistake, nonetheless.

    There's actually a lot written on whether Python or C++ should
    be in charge, especially in a GUIfied context. I haven't the
    time now to assemble good references. You might like to start
    with <URL: http://wiki.tcl.tk/9303 >.
    --

    Cameron Laird <>
    Business: http://www.Phaseit.net
    Personal: http://phaseit.net/claird/home.html
    Cameron Laird, Aug 25, 2003
    #4
  5. Peter Hansen

    Peter Hansen Guest

    Just wrote:
    >
    > In article <bidmuo$90l$>,
    > Zora Honey <> wrote:
    >
    > > [ ... ] The reason I didn't include rationale is
    > > because I have none. I have been advocating extending python instead of
    > > embedding it, but since I have no experience with either, my only
    > > argument is that it seems more natural.

    >
    > Have a look at
    > http://www.twistedmatrix.com/users/glyph/rant/extendit.html
    > It may be a rant, but it makes some good points.


    Rant or no, it does make many of the points I would like to have
    been able to make had I a better grasp of the specifics of
    embedding versus extending. Suffice to say that my objections
    are largely abstract, based on fairly lengthy experience with
    design issues like this, but Glyph's "rant" sure sounds like it
    covers this in a _concrete_ way.

    Zora, your husband isn't necessarily wrong, but probably just
    more comfortable with C++ right now. If that's so, I think he would
    benefit greatly by spending the time to follow Glyph's sound advice,
    and by becoming familiar enough with Python to feel things are
    the other way around: Python calling C++ (or C) is quite a bit
    simpler, and has other advantages in terms of flexibility and
    ease of debugging, not to mention readability.

    -Peter
    Peter Hansen, Aug 25, 2003
    #5
  6. Zora Honey fed this fish to the penguins on Monday 25 August 2003 12:14
    pm:

    > are lot of arguments one way or the other. My husband, on the other
    > hand, is strongly attached to the idea of having a c++ main program
    > that will coordinate all the data-processing classes and python
    > widgets. He believes it is easier to have c++ say to python, "here, I
    > have these plots for you," rather than have python say to c++, "make
    > these plots
    > for me." I don't believe this is true, but I don't have any reason
    > *not* to believe it's true, so I aquiesced.
    >

    Sounds like an attempt to use two separate object-oriented languages
    without defining objects... At least, in the example you cite.

    Since the generation of the plots is, I take it, the CPU intensive
    number cruncher I agree that one would want to code that logic in C/C++.

    But wouldn't a true OO design have created a Plot class? The entire
    class could easily be a C++ extension module -- importable by multiple
    Python applications. Then you'd have things like:

    import plot

    aPlot = plot.Plot()
    #create whatever data drives the plot
    aPlot.generate(data, items)


    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Bestiaria Home Page: http://www.beastie.dm.net/ <
    > Home Page: http://www.dm.net/~wulfraed/ <
    Dennis Lee Bieber, Aug 30, 2003
    #6
  7. Zora Honey <> writes:

    > I'm sorry if I was a bit curt. The reason I didn't include rationale
    > is because I have none. I have been advocating extending python
    > instead of embedding it, but since I have no experience with either,
    > my only argument is that it seems more natural. It seems like either
    > method is as difficult to learn and implement. It doesn't seem to me
    > that there are lot of arguments one way or the other. My husband, on
    > the other hand, is strongly attached to the idea of having a c++ main
    > program that will coordinate all the data-processing classes and
    > python widgets. He believes it is easier to have c++ say to python,
    > "here, I have these plots for you," rather than have python say to
    > c++, "make these plots for me." I don't believe this is true, but I
    > don't have any reason *not* to believe it's true, so I aquiesced.
    >
    > So, I suppose instead of asking you to assume the rationale are well
    > reasoned, I should be asking you why you believe extending python is
    > easier/cheaper/faster/better than embedding it.


    Here's why you're right and your husband is, well... the opposite
    <wink>: embedding Python almost always includes all the problems of
    extending it, and a little bit more. In applications where Python is
    embedded in C++, it's usually insufficient to leave the Python code
    with access to nothing other than what comes with the Python
    interpreter: instead you want to give it access to some C++ types and
    functions. Exposing those to Python is exactly the same job you do
    when extending, only when extending you don't need to worry about
    linking Python into your application (on most platforms), handling and
    reporting Python exceptions from C++ which may emanate from the
    interpreter, getting ahold of a module context in which to evaluate
    Python code, etc. Another way to think of it is that when you need
    to embed, since you also usually need to extend, you need to manage
    the transition across the C++ <-> Python language boundary in two
    places instead of one.

    On the other hand, embedding isn't *much* more difficult, so if it
    keeps things peaceful at home, I'd just go along with it ;-)

    Oh, and whichever you choose, I *strongly* recommend you don't do it
    by hand with Python 'C' API. There are too many ways to mess up
    reference counting, exception-handling, etc., and way too much
    boilerplate code repetition for it to be a very productive approach.
    Besides, since you're using C++ anyway, it gives you all the power you
    need to embed or extend simply and elegantly. For more info, see
    http://www.boost.org/libs/python.

    HTH,
    --
    Dave Abrahams
    Boost Consulting
    www.boost-consulting.com
    David Abrahams, Aug 30, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Darryl

    Embedding Python in Python

    Darryl, Oct 8, 2003, in forum: Python
    Replies:
    6
    Views:
    398
    Darryl
    Oct 14, 2003
  2. Tim Stanka
    Replies:
    2
    Views:
    695
    Giles Brown
    Jul 19, 2004
  3. Phil Frost

    Embedding Python in Python

    Phil Frost, Aug 18, 2004, in forum: Python
    Replies:
    23
    Views:
    769
    Paul Rubin
    Aug 19, 2004
  4. Maurice LING

    embedding python in python

    Maurice LING, Sep 29, 2004, in forum: Python
    Replies:
    8
    Views:
    377
    Jeff Shannon
    Oct 1, 2004
  5. Donnie Leen
    Replies:
    2
    Views:
    280
    Donnie Leen
    Dec 7, 2004
Loading...

Share This Page