NEWBIE: Extending Python with C

[Bengt Richter]

On Sun, 10 Nov 2002 10:51:30 GMT, Alex Martelli <aleax at aleax.it> wrote:

>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).
>
Sounds awful.

>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).
>
Sounds awful too.

>
>> 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.
>
You have certainly painted a gloomy picture. With all due respect,
I'd be interested in hearing Mark Hammond's opinion before totally
giving up.

Regards,
Bengt Richter