Re: Python String Immutability Broken!

[Hendrik van Rooyen]

Patrick Maupin <pmau....ail.co mwrote:

>Very entertaining.
>

Thanks. Nice to see that there is still some sense of humour
left somewhere - its all been so serious here lately - people
seem to forget that hacking is fun!

>But let me get this straight: Are you just complaining that if you
>pass a string to an arbitrary C function using ctypes, that that
>arbitrary function can modify the string?
>

Actually, I am not complaining - I am asking for advice on the side
effects of what I am doing, which is replacing a bunch of bits
in what is essentially an output bit field with the corresponding
input bits at the same addresses read back from a simulated i/o
bus structure. And I would also like to know if there is a better
way of doing this.

The C code actually works, doing what was intended - the \xff that
one sees appearing back comes from the pullup resistors on the
eBox's i/o. I can show that it is working by adding some resistance
and capacitance (by holding the connector against my tongue) in which
case I get a munged version of the fox back. (- evidently my tongue
is not such a perfect communications medium as I would like to believe.)

Passing the fox is actually deceptive and misleading, as in real
use there would be no such correlation sideways across bits, as
they are just representations of output lines.
(Think "coils" in PLC jargon)

>Because if you are, then I think you share a great deal of
>responsibili ty for the death of that string -- sending the poor thing
>to its grave through some unknown C function.

This string is NOT dead - it is alive, and not even stunned -
it just looks as if it is sleeping because of the \xff - which
comes from the fact that there is no real hardware out there yet.

The C functions are very simple ones actually - they just do
what are essentially Linux I/O system calls - setting direction
bits for a port (in or out) and then reading or writing the data.

- Hendrik

[Patrick Maupin]

Re: Python String Immutability Broken!

On Aug 25, 3:31 pm, "Hendrik van Rooyen" <m...@microcorp .co.zawrote:

Actually, I am not complaining - I am asking for advice on the side
effects of what I am doing, which is replacing a bunch of bits
in what is essentially an output bit field with the corresponding
input bits at the same addresses read back from a simulated i/o
bus structure. And I would also like to know if there is a better
way of doing this.

Whenever I do low-level stuff like this, I'm in one of two modes:

Mode #1: I'm using somebody else's C library and the overhead of
doing so is small.

Mode #2: I need to code my own low-level stuff (for speed, IO access,
whatever).

In mode 1, I try not to break out a compiler. ctypes is great for
this, and the results are "pure python" to the extent that you can
give pure python to someone else with the same C library, and it will
work. No muss, no fuss, no makefile, no question that ctypes is
awesome stuff.

In mode 2, I have to break out a compiler. I almost never do this
without ALSO breaking out Pyrex. Pyrex is also awesome stuff, and in
Pyrex, you can easily create a (new) Python string for your results
without having to worry about reference counting or any other really
nasty low level interpreter details. You can code a lot of stuff in
pure Pyrex, and you can easily mix and match Pyrex and C.

Pyrex and ctypes are both tools which let me connect to non-Python
code without having to remember to handle Python interpreter internals
correctly. If I can get by with ctypes, I do, but if I actually have
to code in something other than Python to get the job done, I bypass
ctypes and go straight for Pyrex.