Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #62460 > unrolled thread

bytearray inconsistencies?

Back to article view | Back to comp.lang.python

Contents

  bytearray inconsistencies? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-21 01:06 +0000

#62460 — bytearray inconsistencies?

Quoting from http://docs.python.org/3/library/functions.html#bytearray

"The bytearray type is a mutable sequence of integers in the range 0 <= 
x < 256."

Quoting from http://docs.python.org/3/library/stdtypes.html#bytes-methods

"Whenever a bytes or bytearray method needs to interpret the bytes as 
characters (e.g. the is...() methods, split(), strip()), the ASCII 
character set is assumed (text strings use Unicode semantics).

Note - Using these ASCII based methods to manipulate binary data that is 
not stored in an ASCII based format may lead to data corruption.

The search operations (in, count(), find(), index(), rfind() and 
rindex()) all accept both integers in the range 0 to 255 (inclusive) as 
well as bytes and byte array sequences.

Changed in version 3.3: All of the search methods also accept an integer 
in the range 0 to 255 (inclusive) as their first argument."

I don't understand why the docs talk about "a mutable sequence of 
integers" but then discuss "needs to interpret the bytes as characters". 
  Further I don't understand why the changes done in 3.3 referred to 
above haven't also been applied to (say) the split method.  If I can 
call find to look for a zero, why can't I split on it?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web