Python/D API
David Rushby
David_member at pathlink.com
Thu May 25 19:57:06 PDT 2006
In article <e55d00$nl2$1 at digitaldaemon.com>, Kirk McDonald says...
> That's a really nice package. I've been spending the past day or so
> looking through it. ("Celerid"? Where does that name come from?)
>From "celerity", which means "swiftness of action or motion". It's intended to
refer to the fusion of the development speed of Python with the execution speed
of D.
> It is a pity about DMD not doing dynamic linking outside of
> Windows, though your header is still useful for embedding Python
> in a D program on a Linux system:
Indeed, that's worth noting. However, extending Python with a compiled language
is a vastly more popular option than embedding it in the compiled language.
I can only speak for myself, but the reason I strongly prefer extending Python
to embedding it is that extension is more compatible with my Lispish development
style, which tends toward bottom-up design and loose coupling. My Python
programs are usually structured as loose collections of modules that can be
imported and called by yet-to-be-written code, and some of these modules are
also launchable as standalone programs to perform specific subtasks.
At the outset, I usually launch a given body of code both "the way it would
normally be run" and via a test suite collector. So right there are two "launch
points" that I wouldn't want compiled into a single executable. Also, I often
end up importing and calling code that I wrote months earlier from a context
that I couldn't have foreseen when I wrote the code. Embedding rather than
extending would complicate that approach greatly.
The performance-critical code that I would write in D instead of Python tends to
appear at the lower levels of program organization. In my programs, a given
unit of such code typically concerns itself with *one thing only*, and it is
then combined with other code by a high-level Python module. The coupling
between program units takes place at the Python level, where unforeseen reuse
and radical reorganization are much easier.
So embedding Python in D is an interesting option, but it definitely wouldn't
suit my development style.
More information about the Digitalmars-d
mailing list