Re: Python Strinh Immutability Broken!
Gabriel Genellina: To avoid altering the equilibrium of the whole universe, use ctypes.create_string_buffer: http://python.net/crew/theller/ctypes/tutorial.html#fundamental-data-types Thanks Gabriel – looks like I really have to spend more time with that excellent document. Patrick Maupin: 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). This seems to be where I am at. 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. Don’t know anything about Pyrex except that it is not in the standard library on Suse – will try to read up on it. Thanks. Terry Reedy: http://python.net/crew/theller/ctypes/tutorial.html#arrays Which essentially is the bytearray type of 3.0. How does it differ from plain old array.array(b,”The quick brown fox”)? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Strinh Immutability Broken!
Hendrik van Rooyen wrote:
Terry Reedy:
Which essentially is the bytearray type of 3.0.
How does it differ from plain old array.array(b,”The quick brown fox”)?
The typecode must be quoted as 'b'.
In 3.0, strings become unicode, so an added b prefix is needed.
import array
a = array.array('b', b'fox')
b=bytearray(b'fox')
As to your question: the underlying implementation of bytearrays is
based on that of array('b')s. Bytearrays are built in so no import is
needed. Dir() shows that both have all sequence methods, but arrays
also have list methods, while bytearrays also have string/bytes methods.
They have different representations
a
array('b', [102, 111, 120])
b
bytearray(b'fox')
Bytearrays, like lists/arrays, have the __setitem__ method needed to
make them mutable via indexing.
a[0]=ord(b'b')
b[0]=ord(b'b')
a
array('b', [98, 111, 120])
b
bytearray(b'box')
Arrays can extend bytearrays but not vice versa. This may be a glitch.
c = a + b
Traceback (most recent call last):
File pyshell#24, line 1, in module
c = a + b
TypeError: can only append array (not bytearray) to array
c = b + a
c
bytearray(b'boxbox')
Either can initialize the other
d = array.array('b',c)
d
array('b', [98, 111, 120, 98, 111, 120])
c=bytearray(d)
c
bytearray(b'boxbox')
So if one does more that the common mutable sequence operations, there
is a basis for choosing one or the other.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
