[Python-Dev] Fw: Behavior of buffer()

[Raymond Hettinger]

GvR thought you guys might have some ideas on this one for me.

If I don't get any replies, I may have to rely on my own instincts and
judgment and no one knows what follies might ensue ;)


Raymond Hettinger


----- Original Message -----
From: "Raymond Hettinger" <python@rcn.com>
To: <python-dev@python.org>
Sent: Friday, June 21, 2002 1:16 PM
Subject: Behavior of buffer()


> I would like to solicit py-dev's thoughts on the best way to resolve a
bug,
> www.python.org/sf/546434 .
>
> The root problem is that mybuf[:] returns a buffer type and mybuf[2:4]
> returns a string type.  A similar issue exists for buffer repetition.
>
> One way to go is to have the slices always return a string.  If code
> currently relies on the type of a buffer slice, it is more likely to be
> relying on it being a string as in:  print mybuf[:4].  This is an
intuitive
> guess because I can't find empirical evidence.  Another reason to choose a
> string return type is that buffer() appears to have been designed to be as
> stringlike as possible so that it can be easily substituted in code
> originally designed for strings.
>
> The other way to go is to return a buffer object everytime.  Slices
usually,
> but not always (see subclasses of list), return the same type that was
being
> sliced.  If we choose this route, another issue remains -- mybuf[:]
returns
> self instead of a new buffer.  I think that behavior is also a bug and
> should be changed to be consistent with the Python idiom where:
>   b = a[:]
>   assert id(a) != id(b)
>
> Incidental to the above, GvR had a thought that slice repetition ought to
> always return an error.  Though I don't see any use cases for buffer
> repetition, bufferobjects do implement all other sequence behaviors and I
> think it would be weird to nullify the sq_repeat slot.
>
> I appreciate your thoughts on the best way to proceed.
>
> fixing-bugs-is-easier-than-deciding-appropriate-behavior-ly yours,
>
>
> 'regnitteh dnomyar'[::-1]
>
>
>
>
>
>
>
>
>
>
>
>
>
>