On 9/28/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> Should this PEP include changes to the struct module, or should it be a
> separate PEP?
Neither.
> I would like struct.pack() to return bytes and struct.unpack() to accept
> bytes or buffers but not strings.
This is already the case in 3.0a1.
Should this PEP include changes to the struct module, or should it be a
separate PEP?
I would like struct.pack() to return bytes and struct.unpack() to accept
bytes or buffers but not strings. The 's' and 'p' format specifier
should refer to bytes and not strings.
In protocol encoding and dec
Larry Hastings wrote:
> So now bytes are straddling the difference between strings and the other
> mapping types:
I think the main reason it seems that way is that we're
using a string-like notation for a bytes literal. With
b[i] returning an int, it really behaves just like any
other sequence.
Nick Coghlan wrote:
> However, I do think it may be worth having an additional iterator on
> bytes and buffer objects:
>
>def fragments(self, size=1): # Could do with a better name
I suggest dice(). :-)
--
Greg Ewing, Computer Science Dept, +--+
Universi
Alexandre Vassalotti wrote:
> Personally, I wouldn't mind writing either this:
>
>for b in bytes:
> if b == b'a'[0]:
>pass
Well, I would mind, because it's needlessly verbose
and inefficient.
I still think that c'x' is the least bad solution. As long
as we're wanting to write ar
Guido van Rossum wrote:
I think I've been convinced that b[0] should return an int in range(256).
This made me feel funny. I stared at this for a while:
b'a' != b'abcde'[0] ?!?
b'a'[0] != b'a' ?!?
Then I realized that making b[0] return an int simply makes bytes
objects behave less li
On 9/27/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 9/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > Comparisons
> > ---
>
> > The bytes and buffer types are comparable with each other and
> > orderable, so that e.g. b'abc' == buffer(b'abc') < b'abd'.
>
> I think bytes (regardl
On 9/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Comparisons
> ---
> The bytes and buffer types are comparable with each other and
> orderable, so that e.g. b'abc' == buffer(b'abc') < b'abd'.
I think bytes (regardless of length) should compare to integers, so that:
b"" < -s
On 9/27/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> First, please enforce that where these functions take a "string"
> parameter that they require an octet or octet string (I couldn't find
> what kinds of arguments these functions require in PEP 3118):
>
> >>> x = b'123*45'
> >>> x.find(
I didn't miss it, and I don't disagree, I just don't think it has much
bearing on the discussion (which is whether to go with this proposal
at all).
On 9/27/07, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Thinking through the consequences, and noticing that using the array
> > m
I think I've been convinced that b[0] should return an int in range(256).
To Joel Bender: octet is not, and never will be a technical term for
Python. It is a silly standards body compromise.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
> Making an iterator over an integer sequence acceptable in the
> constructor strongly suggests that a byte sequence contains integers
> between 0 and 255 inclusive, not length 1 byte sequences.
>
> And I think that's the cleanest conceptual model for them as well. A
> byte sequence doesn't con
Guido van Rossum wrote:
> [PEP 3137]
>>> **Open Issue:** I'm undecided on whether indexing bytes and buffer
>>> objects should return small ints (like the bytes type in 3.0a1, and
>>> like lists or array.array('B')), or bytes/buffer objects of length 1
>>> (like the str type). The latter (str-like
On 9/26/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> I think indexing a bytes/buffer object should return an int.
> I find this behavior more natural, to me, than using an
> ord()-like function to extract values.
I didn't known about the length-1 comparison issue when I wrote this.
Person
> **Open Issue:** I'm undecided on whether indexing bytes and buffer
> objects should return small ints (like the bytes type in 3.0a1, and
> like lists or array.array('B')), or bytes/buffer objects of length 1
> (like the str type). The latter (str-like) approach will ease porting
> code from Pyth
Guido van Rossum wrote:
> Thinking through the consequences, and noticing that using the array
> module as an ersatz mutable bytes type is far from ideal, and
> recalling a proposal put forward earlier by Talin, I floated the
> suggestion to have both a mutable and an immutable bytes type. (This
>
Guido van Rossum wrote:
> Please comment.
> [...]
> Conversions between bytes or buffer objects and str objects must
> always be explicit, using an encoding. There are two equivalent APIs:
> ``str(b, [, ])`` is equivalent to
> ``b.encode([, ])``, and
> ``bytes(s, [, ])`` is equivalent to
> ``s.d
Alexandre Vassalotti schrieb:
>> Indexing
>>
>>
>> **Open Issue:** I'm undecided on whether indexing bytes and buffer
>> objects should return small ints (like the bytes type in 3.0a1, and
>> like lists or array.array('B')), or bytes/buffer objects of length 1
>> (like the str type). The
On 9/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [PEP 3137]
> > > **Open Issue:** I'm undecided on whether indexing bytes and buffer
> > > objects should return small ints (like the bytes type in 3.0a1, and
> > > like lists or array.array('B')), or bytes/buffer objects of length 1
> > > (l
On 9/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ...
> Indexing
>
>
> **Open Issue:** I'm undecided on whether indexing bytes and buffer
> objects should return small ints (like the bytes type in 3.0a1, and
> like lists or array.array('B')), or bytes/buffer objects of length 1
> (
Guido van Rossum wrote:
> I'm still undecided (despite Marcin's eloquent argument for ints as
> bytes) but I'm open for votes for this case.
Whatever is done, please don't do it *only* to make
conversion from 2.x easy. There should be good
independent reasons for whatever is chosen.
--
Greg Ewin
On 9/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Constructors
>
>
> There are four forms of constructors, applicable to both bytes and
> buffer:
>
> - ``bytes()``, ``bytes()``, ``buffer()``,
> ``buffer()``: simple copying constructors, with the note
> that ``bytes(
[PEP 3137]
> > **Open Issue:** I'm undecided on whether indexing bytes and buffer
> > objects should return small ints (like the bytes type in 3.0a1, and
> > like lists or array.array('B')), or bytes/buffer objects of length 1
> > (like the str type). The latter (str-like) approach will ease porti
On 9/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Please comment.
>
> PEP: 3137
> Title: Immutable Bytes and Mutable Buffer
> Version: $Revision: 58264 $
> Last-Modified: $Date: 2007-09-26 14:58:29 -0700 (Wed, 26 Sep 2007) $
> Author: Guido van Rossum <[EMAIL PROTECTED]>
> Status: Draft
> T
Please comment.
PEP: 3137
Title: Immutable Bytes and Mutable Buffer
Version: $Revision: 58264 $
Last-Modified: $Date: 2007-09-26 14:58:29 -0700 (Wed, 26 Sep 2007) $
Author: Guido van Rossum <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Sep-2007
Python
25 matches
Mail list logo
