Python String Immutability Broken!

[Patrick Maupin]

On Aug 25, 3:31 pm, "Hendrik van Rooyen" <m... at microcorp.co.za> wrote:
> 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.