ctypes 0.9.2 released
pwatson at redlinepy.com
Sat Nov 27 19:01:43 CET 2004
"Thomas Heller" <theller at python.net> wrote in message
news:mzy58j41.fsf at python.net...
> Ian Bicking <ianb at colorstudy.com> writes:
>> Just wrote:
>>>>One of the perceived strengths of Python is the fact that it
>>>>integrates well with the platforms it is running on, so it's not an
>>>>insulated box like Java.
>>> Another one of Pythons perceived strengths is that if you get a
>>> segfault, it's a bug in Python. With ctypes that will no longer be
>>> as clear.
>> It's always been the case that C extensions can cause segfaults. This
>> is just a tool for incorporating C extensions, without writing any
>> extra C. It even says "c" right in the name, which should cause a
>> certain amount of (justified) fear for anyone who knows what that
>> means ;)
>> Having ctypes in the stdlib would be cool, because it would mean that
>> many C library extension could be installed with no compilation step,
>> since ctypes would already be compiled as part of the default
>> install. Assuming the C library was already installed, but typically C
>> libraries get packaged for distribution long before the associated
>> Python extension is packaged.
> Of course I think that ctypes in the standard lib would be great, but I
> won't try to push this myself anymore. I tried several times in the
> past, and have failed miserably (at least that's how I feel).
The question at hand is "what is the alternative?" Will the user
(developer) need to write code and acquire a compiler? Will that reduce the
probability of a segfault on the Python project?
Also, it is much easier to push an application into an enterprise when
everything comes in one kit. Those who do not know and are making the
decisions return nothing but "NO WAY" when a developer says that we just
need to download something on the Internet... And the discussion ends.
What does the developer do then?
More information about the Python-list