On Thu, Jul 23, 2009 at 8:57 AM, Jean-Paul Calderone<exarkun at divmod.com> wrote: > On Thu, 23 Jul 2009 14:23:56 +0200, Christian Heimes <lists at cheimes.de> > wrote: >> >> Nick Coghlan wrote: >>> >>> I see ctypes as largely useful when you want to call a native DLL but >>> don't have any existing infrastructure for accessing native code from >>> your project. A few lines of ctypes code is then a much better solution >>> than adding a C or C++ compilation dependency just to access a couple of >>> functions. >>> >>> Of course, that definitely isn't the case for CPython - we not only have >>> plenty of existing C infrastructure, but in the specific case of >>> subprocess on Windows we already have a dedicated extension module >>> (PC/_subprocess.c). >> >> You've hit the nail on the head! That's it. >> > > True, CPython has C infrastructure. What about the other Python runtimes, > though? At the language summit, there was a lot of discussion (and, I > thought, agreement) about moving the standard library to be a collaborative > project between several of the major runtime projects. A ctypes-based > solution seems more aligned with this goal than more C code. > > Jean-Paul Yeah, I remember that too - all of us discussed "breaking out" the stdlib post mercurial migration to be shared amongst all of the implementations, marking CPython things as "CPython only" and so on. That way we all have a common base to work from. jesse
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4