Georg Brandl wrote:
> Seeing that, I made a patch that makes bytes_repr output a bytes literal,
I'm not sure that's a good idea. Any given bytes object
is as likely to have been constructed using bytes(...)
as using b"...". There's no way of being sure whether
displaying it as a string is appropr
I'm not sure what makes you say that. There isn't anyone actually using
bytes() right now, so what makes you think how it's created? Besides, lists
can be created with list("foo") too, but they still repr() as ['f', 'o',
'o'].
On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Georg Brandl wrote
Travis Oliphant wrote:
>2. There is no way for a consumer to tell the protocol-exporting
> object it is "finished" with its view of the memory and therefore no way
> for the object to be sure that it can reallocate the pointer to the
> memory that it owns (the array object reallocating its
Thomas Wouters wrote:
>
> I'm not sure what makes you say that. There isn't anyone actually using
> bytes() right now, so what makes you think how it's created?
That's my point -- you *don't* know how any given bytes
object was created, so there's no reason to display it
in anything other than t
Greg Ewing wrote:
> Another thing is that the idea of displaying a mutable
> object in a way that closely resembles a non-mutable
> literal makes me uncomfortable. Actually, writing that
> sort of literal makes me uncomfortable too, but I'm
> not sure what to do about that.
We obviously need anot
On Mon, 26 Feb 2007 11:15:20 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Thomas Wouters wrote:
>>
>> I'm not sure what makes you say that. There isn't anyone actually using
>> bytes() right now, so what makes you think how it's created?
>
>That's my point -- you *don't* know how any given bytes
>
I think you're confused. There isn't anything 'less generic' about the bytes
literal. Both bytes([...]) and b"..." can express the full 256 value range.
On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:
>
> I'm not sure what makes you say that. There isn't anyone actually
Greg Ewing <[EMAIL PROTECTED]> wrote:
> That's my point -- you *don't* know how any given bytes
> object was created, so there's no reason to display it
> in anything other than the most generic way.
Practicality beats purity here, I think. For example, if I'm
debugging a network protocol, I'd pr
>>> x = b'a'
>>> x[0] = b'a'
Traceback (most recent call last):
File "", line 1, in
TypeError: 'bytes' object cannot be interpreted as an index
Huh? 0 is not a 'bytes' object and I don't see how the RHS is being
used as an index. Obviously I wanted something like:
>>> x[0] = ord(b'a')
_
On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Travis Oliphant wrote:
>
> >2. There is no way for a consumer to tell the protocol-exporting
> > object it is "finished" with its view of the memory and therefore no way
> > for the object to be sure that it can reallocate the pointer to the
>
This is because a bytes object is not a sequence of bytes objects, like
strings. It's a sequence of small integer values, so you need to assign a
small integer value to it. You can assign b'a'[0] to it, or assign b'a' to
x[:1]. I guess we could specialcase length-1 bytes to make this work
'natural
Thomas is correct. You can only assign ints in range(256) to a single
index. This would work:
x[:1] = b"a"
The error comes from the call to PyNumber_AsSsize_t() in
bytes_setitem(), which apparently looks for __index__ or the tp_index
slot.
--Guido
On 2/25/07, Thomas Wouters <[EMAIL PROTECTED]>
Thomas Wouters schrieb:
This is because a bytes object is not a sequence of bytes objects, like
strings. It's a sequence of small integer values, so you need to assign
a small integer value to it. You can assign b'a'[0] to it, or assign
b'a' to x[:1]. I guess we could specialcase length-1 byt
No, I don't want length-1-bytes to get special treatment here. That
would just perpetuate confusion, since b[0] *returns* an int no matter
what you might have set it to.
--Guido
On 2/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Thomas Wouters schrieb:
> >
> > This is because a bytes object is
On Sun, Feb 25, 2007 at 05:40:12PM -0600, Guido van Rossum wrote:
> Thomas is correct. You can only assign ints in range(256) to a single
> index.
Yes, I understand that. I think the error message is bad though.
> The error comes from the call to PyNumber_AsSsize_t() in
> bytes_setitem(), which
Correct (I wasn't saying it was used on the lhs operand :-).
I find it important to use that API since anything that wants to
behave like a (small) int should be acceptable. Can you suggest a
better way to formulate the error from that API?
--Guido
On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]
Jean-Paul Calderone wrote:
> > Actually, writing that
> > sort of literal makes me uncomfortable too, but I'm
> > not sure what to do about that.
>
>[1, 2, 3]
>(1, 2, 3)
Not quite sure what your point is. My point is that
I'm thoroughly conditioned to think of anything in
quotes as immutab
Thomas Wouters wrote:
>
> I think you're confused. There isn't anything 'less generic' about the
> bytes literal. Both bytes([...]) and b"..." can express the full 256
> value range.
Yes, but it only makes sense to try to display it as
characters if it's meant to represent characters in
the fir
Neil Schemenauer wrote:
> Practicality beats purity here, I think. For example, if I'm
> debugging a network protocol, I'd prefer
>
> b"EHLO ...\x0d\x0a"
But what if I'm *not* debugging a network protocol,
and my bytes objects all look like random gibberish
when displayed as characters?
To
Guido van Rossum wrote:
> I find it important to use that API since anything that wants to
> behave like a (small) int should be acceptable.
But by calling __index__ and giving error messages about
indexes, PyInt_AsSsize_t seems to be assuming that the
value is going to be used as an index.
If t
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Thomas Wouters wrote:
> >
> > I think you're confused. There isn't anything 'less generic' about the
> > bytes literal. Both bytes([...]) and b"..." can express the full 256
> > value range.
>
> Yes, but it only makes sense to try to display it as
> c
On 2/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> But if they're displayed as characters by default,
> what do I do to get them displayed as not-characters?
Well anything that's not an ASCII printable is \x escaped anyway. If
you want all hex, use the .hex() method described in the PEP.
--
--G
Please give the poor function a break. It was added to 2.5 and used
only for indexing there. In 3.0 it is more generally useful (I want to
use it whenever an int is needed). but in our pre-alpha code the error
messages haven't been fixed yet. That's the whole story.
On 2/25/07, Greg Ewing <[EMAIL
23 matches
Mail list logo
