NEWBIE: Extending Python with C

[Dennis Lee Bieber]

engsol at teleport.com fed this fish to the penguins on Sunday 10 November 
2002 01:59 pm:

> 
> The application provides a console-like user interface, command line
> style. The app has the facility to run 'scripts', loosely based on a
> C-like syntax, which is how we write our test scenarios to automate
> product software testing. The app also has "drivers" to run the cards,
> IO ports, user interface, etc.
>

        Okay, we have a scriptable user interface...
 
> job, we're out of memory (lots of page swapping/overlays), speed is an
> issue (we really need an RTOS....events of interest are
> sub-millisecond now), background sequencers are at their limits
> (threads would be nice), on and on. Plus it locks up a lot these days,
> which is not good when trying to run a two day test suite over the
> weekend.
>
        Need speed, and some access to a posix thread system...
 
> Soooo what is the new tool to look like? Which platform/OS is the
> "right" one? Which script language would provide the testers with what
> they need? Having to compile scripts, if it were C or C++, doesn't
> seem like a good idea, and not very newbie friendly. Perl, while
> powerful,is a bit obtuse. TCL is a bit limited, although named pipes
> are handy. Plus, "bread-boarding" quickie tests from the command line
> would be awkward at best. How
> best to implement a user GUI, and still maintain a command line
> interface?  We're in the exploration mode, as it were, to answer some
> of these questions.
> 
        Need a non-compiled script language...

> 
> Then the thought occurs....will we be forced to write some things in
> C/C++? ISRs? RTOS interface? Driving the custom cards? Timers? I don't
> know, but it's possible there will be some tasks which will benefit
> from extending Python. If so, what's involved? How do you do
> that...exactly? This is why I posted the request for help/info to this
> great newsgroup. I need to figure out the process of extending
> Python...if it's needed.
>

        IMO, I'm going to present some bad news...

        From what you've said, I'd almost think you were coming at it from the 
wrong direction. 

        /I/ think what you'll end up with is a C/C++ application with an 
embedded Python interpreter for your scripting, and maybe for part of 
the graphical part of the user-interface... But the rest of the 
application strongly sounds like it needs to be ported to a different 
OS (drop the MS-DOS mode for Windows or Linux) and cleaned up -- 
remaining in C or rewritten in C++.

        Python threads are switched based upon n-bytecodes of execution (if I 
recall, that is something like every 10 or 20 bytecodes in the 
interpreter). We just had a long discussion a few weeks ago on how 
invoking a "simple" exponential operation using on LONG integers (which 
is performed by a C runtime routine) results in a long lockout in 
Python.

        "Extending" Python is more applicable to things like library 
packages... Say you have a library of statistical functions written in 
C. The library doesn't do anything useful on its own, you need to have 
an application calling the functions in a meaningful order. You would 
like to be able to develop statistical applications in Python, but 
don't want to code all the stat-functions in Python -- so you "extend" 
Python by making wrappers that can call the C library functions.

        "Embedding" lets your application invoke Python to process program 
statements.

        Actually, now that I think about it, you may really be looking at 
having to do both sides... Embed Python for your console/scripting and 
maybe for the GUI, and extend it so the scripts and GUI can directly 
call the processing code you have in C. Either way, you'll have to get 
your code to build under the graphical OS, which ever one you finally 
pick.

        I'll speak blasphemy -- I wonder if it might not be worth recoding 
totally, into something like Ada (GNAT/AdaGIDE on Windows). Since Ada 
was designed for use on embedded systems (even if GNAT doesn't build 
for pure embedded systems) it includes syntax for specifying hardware 
level access (though, again, I have no experience on how difficult it 
is to use that under Windows).
 
> To end my rambling...the answer to the driver question above has
> answered itself, I think. Why would I want to port a 16-bit DOS module
> to NT/2K/Linux, as is? Thanks to the discussion on this helpful
> newsgroup..I don't think I do. But I still need to understand the
> process of adding Python modules, when to use DLLs if it makes sense,
> how to expose them to Python, how to use them, etc. I need the
> "process"...I can figure out the code, I hope...:)
> 
> (Now, if I can just find a good COM book per Alex's suggestions.....)
> 
> Regards,
> Norm

-- 
--  
 > ============================================================== <
 >   wlfraed at ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
 >      wulfraed at dm.net     |       Bestiaria Support Staff       <
 > ============================================================== <
 >        Bestiaria Home Page: http://www.beastie.dm.net/         <
 >            Home Page: http://www.dm.net/~wulfraed/             <