Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Mark Lawrence <breamoreboy@yahoo.co.uk>
Subject: Re: bytearray inconsistencies?
Date: Sat, 21 Dec 2013 02:31:48 +0000
References: <l92phr$3b2$1@ger.gmane.org> <l92sju$ugd$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <l92sju$ugd$1@ger.gmane.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4450.1387593133.18130.python-list@python.org>
Lines: 57
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:62464

On 21/12/2013 01:58, Ned Batchelder wrote:
> On 12/20/13 8:06 PM, Mark Lawrence wrote:
>> 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".
>
> The split and strip methods work with whitespace when given no
> arguments.  Bytes aren't whitespace.  Characters can be, so the bytes
> need to be interpreted as characters.  Likewise, the is* methods
> (isalnum, isalpha, isdigit, islower, isspace, istitle, isupper) all
> require characters, so the bytes must be interpreted.
>
>>   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?
>>
>
> I don't know the reason, but I would guess either no one considered it,
> or it was deemed unlikely to be useful.

Explanation, or lack of it, here http://bugs.python.org/issue12170

>
> If you have a zero, you can split on it with:
> bytestring.split(bytes([0])), but that doesn't explain why find can take
> a simple zero, and split has to take a bytestring with a zero in it.
>

I now have working code as a result of the above paragraph, thanks for 
that :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence