Re: Python API options?

[Michael Gogins <michael.gogins@...>]

You should be able to do quick and dirty C or C++ programming with
ease if you simply eliminate build system complexities. And that's not
hard at all:

(1) Create 3 simple build scripts that will take 1 source code file
and compile it to a program, library, or shared library. This script
will simply specify all the include paths, library paths, and
libraries you would want along with common build options (e.g. -g -O2
-march whatever). The key is it should compile only one source file.
Invocations would be like "build myprogram.c" or "buildlib mylib.c" or
"buildso myso.c". It will not hurt you much to include all kinds of
libraries that you don't always link with on the link line.

(2) Obviously, write your applications (whether programs or libraries)
as one single source file. There is nothing wrong with this. Modern
computers and compilers allow a single compilation unit to be quite
large. This is not likely to limit you.

(3) Write any of your own libraries that you may wish to re-use across
applications as header files only. Again, there is nothing wrong with
this and it is becoming fairly common for C++ libraries. If you need
to define objects in your libraries, do them in scope of static
functions that can be both declared and defined in a header file, e.g.
instead of

GlobalStruct myGlobalStruct;

at file scope in a source file, do this instead in a header file:

GlobalStruct *myGlobalStruct()
{
    static GlobalStruct myGlobalStruct_;
    return &myGlobalStruct_;
}

And obviously, all function bodies will be inline (they will run
faster that way also).

With current computers and toolchains, this approach is more or less
as easy and quick to work with as a dynamic language.

One big advantage of working this way is that, since you should always
compile with -g -O2, you can always use a real debugger on your
applications whenever you want.

Regards,
Mike

P.S. This doesn't mean I don't love LuaJIT -- that would be for
programs and libraries to be distributed to people who don't
necessarily have or want the C compiler, or for embedding.

On Tue, Mar 8, 2011 at 8:21 AM, Alex Bradbury <asb@asbradbury.org> wrote:
> On 8 March 2011 13:04, Patrick Mc(avery
> <spell_gooder_now@spellingbeewinnars.org> wrote:
>> I found Lunatic-Python
>>
>> http://niemeyer.net/lunatic-python
>>
>> but it does not seem to build out of the box and I fear this approach may
>> have been abandoned. I believe io.popen is just one way in Lua, so I am
>> assuming this is not a great solution or is there a two way approach?. Does
>> anyone have any tips on using Python with Lua or perhaps other workarounds
>> to access the large library base?
>
> I haven't tried to use it, but Lupa seems to be the most
> actively-developed option (though is targeted more towards the Python
> community wanting to leverage LuaJIT):
> http://pypi.python.org/pypi/lupa/
>
> There's also ltcltk (http://tset.de/ltcltk/) to bind to tcl, which has
> some good libraries.
>
> Alex
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com