ctypes 0.9.2 released

[Thomas Heller]

ctypes 0.9.2 released - Oct 28, 2004
====================================

Overview

ctypes is a ffi (Foreign Function Interface) package for Python
2.3 and higher.

ctypes allows to call functions exposed from dlls/shared libraries
and has extensive facilities to create, access and manipulate
simple and complicated C data types in Python - in other words:
wrap libraries in pure Python. It is even possible to implement C
callback functions in pure Python.

ctypes runs on Windows, MacOS X, Linux, Solaris, FreeBSD, OpenBSD.
It may also run on other systems, provided that libffi supports
this platform.

On windows, ctypes contains a ctypes.com package which allows to
call and implement custom COM interfaces.

Important

If you download the source distribution, please choose the ZIP
file for Windows, and the .tar.gz file for other systems.
These archive have different contents!

Changes in 0.9.2

Fixed several bugs and memory leaks.

ctypes is now tested on Windows, Linux (x86 and x86_64), OpenBSD
and Mac OS X.

Implemented some helper functions: memmove, memset, string_at, wstring_at.
The former act as their C library counterpart, the latter two allow
to read a zero-terminated (wide) strings at a certain address.

Implemented a cast(cobj, ctype) function, which creates a new object
of the specified ctype from an existing object.

ctypes now explicitely allocates executable memory for the callbacks
it creates, this makes it work correctly on platforms where
executing data is normally forbidden (OpenBSD, Win XP SP2 on AMD 64).

Fixed the unicode handling on non-windows platforms.

Bit fields in structures and unions are now implemented.
For a bit field, one would specify the width in bits as the third
part in the _fields_ list like this:

class BitFieldSample(Structure):
_fields_ = [("anInt", c_int),
("aBitField", c_int, 3)]

POINTER(None) now returns c_void_p. This change was made for easier
code generation, and makes sense since 'None' is the ctypes way to
spell 'void'.
Detailed changelogs are in CVS:

<http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/ChangeLog?rev=HEAD>

<http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/win32/com/ChangeLog?rev=HEAD>
Future plans

The ultimate purpose of the 0.9 release series is to shake out the
remaining bugs, especially on platforms I have no access to, and
to target a rock stable ctypes 1.0 release.

When ctypes 1.0 is released, the com framework will be split off
into a separate framework named 'comtypes'.
Download

Downloads are available in the sourceforge files section
<http://sourceforge.net/project/showfiles.php?group_id=71702>

Separate source distributions are available for windows and non-windows systems.
Please use the .zip file for Windows (it contains the ctypes.com framework),
and use the .tar.gz file for non-Windows systems (it contains the
complete cross-platform libffi sources).

Binary windows installers, which contain compiled extension
modules, are also available, be sure to download the correct one
for the Python version you are using.
Homepage

<http://starship.python.net/crew/theller/ctypes/>

Enjoy,

Thomas

[Ganesan R]

>>>>> "Thomas" == Thomas Heller <th*****@python.net> writes:

Future plans
The ultimate purpose of the 0.9 release series is to shake out the
remaining bugs, especially on platforms I have no access to, and
to target a rock stable ctypes 1.0 release.
When ctypes 1.0 is released, the com framework will be split off
into a separate framework named 'comtypes'.

Congratulations! I maintain ctypes for debian. I am holding off uploading
the 0.9 versions because they don't support Python 2.2. A Python 2.2 package
was present in debian for ctypes 0.6.2, I want to be sure that no one is
using it before uploading 0.9.x.

That aside, I am wondering if it isn't time to push ctypes for inclusion
into the standard Python distribution. Too late for Python 2.4, but how
about Python 2.5?

Ganesan

[Alex Martelli]

Ganesan R <rg******@myrealbox.com> wrote:
...

That aside, I am wondering if it isn't time to push ctypes for inclusion
into the standard Python distribution. Too late for Python 2.4, but how
about Python 2.5?

Seconded! Python 2.5 should be mostly about standard-library
enhancements, and ctypes would be a huge enhancement to Python's stdlib.
Alex

[Just]

In article <1g*****************************@yahoo.com>,
al*****@yahoo.com (Alex Martelli) wrote:

Ganesan R <rg******@myrealbox.com> wrote:
...

That aside, I am wondering if it isn't time to push ctypes for inclusion
into the standard Python distribution. Too late for Python 2.4, but how
about Python 2.5?

Seconded! Python 2.5 should be mostly about standard-library
enhancements, and ctypes would be a huge enhancement to Python's stdlib.

In general, Guido is very reluctant to accept thing which make is easy
to cause segfaults. I predict you'll have a very hard time convincing
him...

Just

[Alex Martelli]

Just <ju**@xs4all.nl> wrote:
...

enhancements, and ctypes would be a huge enhancement to Python's stdlib.

In general, Guido is very reluctant to accept thing which make is easy
to cause segfaults. I predict you'll have a very hard time convincing

Good point -- and a very sound stance by Guido, of course.
Alex

[Peter Hansen]

Just wrote:

In article <1g*****************************@yahoo.com>,
al*****@yahoo.com (Alex Martelli) wrote:

Seconded! Python 2.5 should be mostly about standard-library
enhancements, and ctypes would be a huge enhancement to Python's stdlib.

In general, Guido is very reluctant to accept thing which make is easy
to cause segfaults. I predict you'll have a very hard time convincing
him...

That's too bad, because it's really not that easy to cause segfaults
with it.

I'm speaking practically, as someone who has used ctypes in a dozen
different utilities and applications, and who hasn't always read the
docs, and who has experimented sometimes in ways that in a language
like C would cause segfaults, but with ctypes: no segfaults to date.

I'm obviously not saying it's not possible to cause segfaults
with ctypes. Almost anyone could probably come up with a way in a
few minutes or less.

I _am_ saying that casual use over the period of several years
has not led to any segfaults for _me_, and the benefits have
been huge.

Nobody is forcing someone to use ctypes, and I suppose if one
chooses to use it, one probably has some idea of the dangers of
what one is doing.

Of course, nobody is forcing anyone to include ctypes in the
standard distribution either, but it seems that the choice should
be made based more on what ctype's *users* think about it than
what someone who perhaps has rarely or never actually used it
thinks. Or is Guido a regular ctypes user (and presumably one
who has often triggered unexpected segfaults, at that)?

-Peter

[Alex Martelli]

Peter Hansen <pe***@engcorp.com> wrote:

Of course, nobody is forcing anyone to include ctypes in the
standard distribution either, but it seems that the choice should
be made based more on what ctype's *users* think about it than
what someone who perhaps has rarely or never actually used it

ctypes' users can keep using it. Putting it in the std distro would
encourage a bazillion others to use it -- there's the rub.
Alex

[Peter Hansen]

Alex Martelli wrote:

Peter Hansen <pe***@engcorp.com> wrote:

Of course, nobody is forcing anyone to include ctypes in the
standard distribution either, but it seems that the choice should
be made based more on what ctype's *users* think about it than
what someone who perhaps has rarely or never actually used it

ctypes' users can keep using it. Putting it in the std distro would
encourage a bazillion others to use it -- there's the rub.

I suppose that's true... it's definitely not hard to download
and install.

Hmm... this leads me to think that maybe what would be a good
idea is a small set of "anthology" distributions of a number
of related packages, allowing a "canned" installation of a
bunch of useful stuff at the same time.

I'm thinking specifically of things that would be appropriate
in the controls field, such as PySerial and ctypes, but I'm
sure other industry-specific collections could easily be
discerned.

That idea, turned into something more concrete, might be
enough to fill in the gap between the standard distribution
and the hundreds of discrete little packages which are scattered
around on myriad web sites.

-Peter

[Ville Vainio]

>>>>> "Just" == Just <ju**@xs4all.nl> writes:

Seconded! Python 2.5 should be mostly about standard-library
enhancements, and ctypes would be a huge enhancement to Python's stdlib.

Just> In general, Guido is very reluctant to accept thing which
Just> make is easy to cause segfaults. I predict you'll have a

Why is that? Users of ctypes can quite easily understand that when
they are using ctypes, they are not using Python but rather
integrating Python with the environment. Of course using pure Python
code (and integrating with only the C code that is bundled with the
distribution) shouldn't segfault, but with ctypes tho user will know
that the third party code is to blame.

Or are there some security issues?

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.

--
Ville Vainio http://tinyurl.com/2prnb

[Alex Martelli]

Peter Hansen <pe***@engcorp.com> wrote:
...

Hmm... this leads me to think that maybe what would be a good
idea is a small set of "anthology" distributions of a number
of related packages, allowing a "canned" installation of a
bunch of useful stuff at the same time.
Sure. That's a reasonable alternative to the "Sumo Distribution"
approach best typified by Enthought's huge (and I believe Windows-only)
excellent one for scientific work with Python.
That idea, turned into something more concrete, might be
enough to fill in the gap between the standard distribution
and the hundreds of discrete little packages which are scattered
around on myriad web sites.

Sure, it is one way. Other approaches include sumo distributions, and
others yet, such as Macpython's package-manager, Activestate's somewhat
cpan-like arrangement, etc, etc.

The problem I can see with "sets of a dozen interrelated packages" is:
what happens to users who need two of them, when the two packages use
and include the same extension... in two different versions...
Alex

[Just]

In article <du*************@mozart.cc.tut.fi>,
Ville Vainio <vi***@spammers.com> wrote:

>> "Just" == Just <ju**@xs4all.nl> writes: >> Seconded! Python 2.5 should be mostly about standard-library
>> enhancements, and ctypes would be a huge enhancement to Python's
>> stdlib.

Just> In general, Guido is very reluctant to accept thing which
Just> make is easy to cause segfaults. I predict you'll have a

Why is that? Users of ctypes can quite easily understand that when
they are using ctypes, they are not using Python but rather
integrating Python with the environment. Of course using pure Python
code (and integrating with only the C code that is bundled with the
distribution) shouldn't segfault, but with ctypes tho user will know
that the third party code is to blame.

Or are there some security issues?

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.

There's also a practical problem with including ctypes (unless it's an
optional module, like bsddb) is that it depends (at least on unix) on a
rather large and complex library: libffi.

I personally love ctypes, although I haven't used it in real projects
yet. It's a wonderful package. But I don't think it's a good fit for the
std library (regardless of the arguments above).

Just

[Peter Hansen]

Alex Martelli wrote:

Peter Hansen <pe***@engcorp.com> wrote:
The problem I can see with "sets of a dozen interrelated packages" is:
what happens to users who need two of them, when the two packages use
and include the same extension... in two different versions...

Uh, test first? Why don't we try it and see how big a problem
it is? (Using the impersonal "we", of course. :-)

-Peter

[Ian Bicking]

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.

--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org

[Thomas Heller]

Ian Bicking <ia**@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).

Thomas

[Thomas Heller]

Ganesan R <rg******@myrealbox.com> writes:

>> "Thomas" == Thomas Heller <th*****@python.net> writes:

Future plans
The ultimate purpose of the 0.9 release series is to shake out the
remaining bugs, especially on platforms I have no access to, and
to target a rock stable ctypes 1.0 release.
When ctypes 1.0 is released, the com framework will be split off
into a separate framework named 'comtypes'.

Congratulations! I maintain ctypes for debian. I am holding off uploading
the 0.9 versions because they don't support Python 2.2. A Python 2.2 package
was present in debian for ctypes 0.6.2, I want to be sure that no one is
using it before uploading 0.9.x.

When I gave up support for Python 2.2, I didn't realize that all the
platforms on sourceforge's compile farm still have Python 2.2. I had to
configure a install a private 2.3 or newer version myself, although
probably I learned a lot from that.

When will the linux distributions switch from 2.2 to a newer version?
I understood that redhat probably had their reasons to stay with 1.5.2
for quite a long time, but are there similar reasons for other distributions?

Thomas

[Max M]

Ian Bicking wrote:

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.

ctypes are sweet!

Trying them out, I was surprised how easy it was to do ... well anything.

I am not aware af all the consequences of including it in the standard
library, but to me it seems like a logical thing to do. It "feels" very
pythonic.


--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

[Jeremy Bowers]

On Fri, 29 Oct 2004 21:02:07 +0200, Thomas Heller wrote:

When will the linux distributions switch from 2.2 to a newer version?
I understood that redhat probably had their reasons to stay with 1.5.2
for quite a long time, but are there similar reasons for other distributions?

Yeesh, this is still an issue? Even Gentoo has moved on to 2.3, and I felt
like it took a while.

That makes sense because while Gentoo is a "bleeding edge" distro, the
core "emerge" and "portage" stuff is all written in Python. Moving Python
versions requires porting the entire distro, which while that probably
isn't a lot of work in the absolute sense is certainly a lot of testing.
Thus, this is more significant than a non-Python distro. (I expect this is
why there is no ebuild for 2.4 yet; normally there would be one marked
with the unstable flag "~x86", but it probably ends up breaking the entire
distro or something if you install that as /usr/bin/python, and it would
cause other havoc for this particular package to install it as python2.4
now, and try to change that later. Though I could be wrong.)

I just checked and 2.3.4 isn't even marked unstable for x86.

I'm surprised that they don't even have them as options; Python does OK as
"pythonX.X" in general.

[Nelson Minar]

ctypes looks very powerful, and the convenience of doing everything at
runtime seems significant. To what extent is it a replacement for swig
for calling C code? I haven't really used ctypes, so I'm asking.

Are there jobs that swig is better at and jobs that ctypes is better
at? ctypes requires your code be in a dynamic library, and that ctypes
is for C only. But those don't seem like major drawbacks for my uses.
I did a bit of research on this question and all I found was this:
http://sourceforge.net/mailarchive/m...msg_id=6887157

I have been thinking about instead of swig using ctypes and some
form of automated header parser to make a new pyopengl

[Ganesan R]

>>>>> "Thomas" == Thomas Heller <th*****@python.net> writes:

Ganesan R <rg******@myrealbox.com> writes:

>>> "Thomas" == Thomas Heller <th*****@python.net> writes:

Future plans
The ultimate purpose of the 0.9 release series is to shake out the
remaining bugs, especially on platforms I have no access to, and
to target a rock stable ctypes 1.0 release.
When ctypes 1.0 is released, the com framework will be split off
into a separate framework named 'comtypes'.

Congratulations! I maintain ctypes for debian. I am holding off uploading
the 0.9 versions because they don't support Python 2.2. A Python 2.2 package
was present in debian for ctypes 0.6.2, I want to be sure that no one is
using it before uploading 0.9.x.

When I gave up support for Python 2.2, I didn't realize that all the
platforms on sourceforge's compile farm still have Python 2.2. I had to
configure a install a private 2.3 or newer version myself, although
probably I learned a lot from that. When will the linux distributions switch from 2.2 to a newer version?
I understood that redhat probably had their reasons to stay with 1.5.2
for quite a long time, but are there similar reasons for other distributions?

Debian switched to Python 2.3 as default quite a while back. If you install
python-ctypes in python you get python2.3-ctypes by default. You need to
explicitly install python2.2-ctypes if you want Python 2.2 support.

It's just that I need to remove python2.2-ctypes package if I upload a
0.9.x version of ctypes. If some one is still interested in Python 2.2
support, I may have to package both 0.6.2 (under a different name, say
ctypes062) and 0.9.2.

Ganesan

[Paul Watson]

"Thomas Heller" <th*****@python.net> wrote in message
news:mz**********@python.net...

Ian Bicking <ia**@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).

Thomas

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?