ctypes 0.9.2 released

[Max M]

Re: ctypes 0.9.2 released

Ian Bicking wrote:
[color=blue]
> 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.[/color]


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]

Re: ctypes 0.9.2 released

On Fri, 29 Oct 2004 21:02:07 +0200, Thomas Heller wrote:[color=blue]
> 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?[/color]

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 vs. swig

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/message.php?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]

Re: ctypes 0.9.2 released

>>>>> "Thomas" == Thomas Heller <theller@python .net> writes:
[color=blue]
> Ganesan R <rganesan@myrea lbox.com> writes:[color=green][color=darkred]
>>>>>>> "Thomas" == Thomas Heller <theller@python .net> writes:[/color]
>>[color=darkred]
>>> 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'.[/color]
>>
>> 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.[/color][/color]
[color=blue]
> 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.[/color]
[color=blue]
> 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?[/color]

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]

Re: ctypes 0.9.2 released

"Thomas Heller" <theller@python .net> wrote in message
news:mzy58j41.f sf@python.net.. .[color=blue]
> Ian Bicking <ianb@colorstud y.com> writes:
>[color=green]
>> Just wrote:[color=darkred]
>>>>One of the perceived strengths of Python is the fact that it
>>>>integrate s 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.[/color]
>>
>> 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.[/color]
>
> 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[/color]

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?