NEWBIE: Extending Python with C

[Alex Martelli]

Bengt Richter wrote:

> On Sat, 09 Nov 2002 08:02:43 GMT, Alex Martelli <aleax at aleax.it> wrote:
> [...]
>>
>>This is more or less the end of the line in terms of what
>>os.popen can offer -- due to buffering and suchlike there's
>>no practical way for python to drive BOTH standard input
>>and standard-output of another external program.
> 
> I think there *ought* to be a practical way, *and* amongst the batteries
> ;-)
> 
> It's hard to believe that, for NT at least, someone out there
> hasn't written a console proxy module that could interface to console
> apps the way typing and viewing in a console window does, so something

Never heard of one, as such, but the existence of an `expect` port
to NT (done, as I recall, by intercepting a spawned process's calls
to system console functions, which in turn took advantage of many
curious quirks -- e.g., that setting breakpoints in system DLL's
caused the system to copy-on-write duplicate specific pages of the
system DLL's thus affected) does suggest something can be kludged
up.  Probably not very solidly -- again I'm relying on memories of
the "expect for NT" issues: if a spawned process got exceptions or
multithreaded intensely the spawning process would eventually lose
track of things.  And definitely not in such a way as to work for
systems in the /95-/98-/ME line (no idea what would happen were one
to try to reproduce those quirks in /2K-/XP -- particularly the
"workstation"/"home" editions: MS, as I recall, was quite careful to 
hobble them, particularly XP, to make sure the cheaper editions could
not be used for "server-oid" functions, i.e. that one would have to
buy costlier editions for the purpose).

Cameron Laird posted a thoughtful critique of 'expect' recently on
this group.  Combining those reflections, and the specific ones on
the frailty and non-portability of the 'expect for NT' approach,
lead me to consider that trying to make such functionality part of
the Python standard library would be at best wasted effort (if one
gave up when the unfeasibility became apparent) and at worst a
tragedy (if one was able to block Python's next release indefinitely
while trying to make the needed kludges semi-workable).


> As you point out, TMTOWTDI applies in spades, but if there's
> a solid way to run a program to do what you want from the
> console window command line, why shouldn't there be a solid
> way to use that via something like the above? (Especially handy for
> those who don't have compilers or ready knowledge to make C extensions).

I think there shouldn't be yet another, semi-functional, not
really portable, highly-kludgy way to attempt to provide a
functionality that the underying OS doesn't support or even
actively fight against.  People who don't have compilers &c
are better advised (for Windows-only deployment) to use COM
for most purposes, anyway.


Alex