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

[Scott Gilbert]

--- Guido van Rossum wrote:
>
> I'm a little surprised.  Raymond Hettinger checked in a change that
> makes all slices of buffer objects return strings.  His comments on SF
> bug 546434 say that only one person replied and that they agreed
> returning strings was the better solution.  But that's not how I read
> the only response to his query that I see in python-dev, from Scott
> Gilbert:
> 

After the message you're referring to, Raymond Hettinger and I corresponded
a little bit off of the list.  I think these are probably the most relevant
snippets:

--- Raymond Hettinger:
> 
> For the problem at hand, do you recommend returning buffer objects or
> strings?
> 

--- To which I responded:
>
> I wish I could give you an easy A or B answer.  What I would like to see
> is for the PyBufferObject to be nothing more than a BufferInspector.  As
> such, it would make more sense to have slices return another BufferObject
> that is inspecting the same data.  In other words, "View Behavior".  In 
> this context, repetition of buffer objects doesn't make any sense and 
> should raise an exception.
> 
> However, that's going to break somebody's code somewhere, so I can't see
> Guido allowing that for a problem he doesn't really care about.  I think
> you're stuck returning strings until Python 3000.  So the best bet would
> be to have it just always return a string...
> 

Forgive the bit about "Guido not caring about it", it seemed that way to
me at the time.  Silence comes off as disinterest or annoyance.

So my suggestion was that since taking away the implicit promotion of
buffer slices/repetitions/concatenations to strings was going to break
someone's code, that just can't be done.  If we want sane behavior, then
any slice, be it buf[1:2] or buf[:], ought to at least return the same type
of object.  Those two in conjunction mean they ought to always returns
strings.



--- Raymond Hettinger also wrote:
> 
> Thanks for your input, this topic doesn't seem to interest anyone,
> 

--- To which I responded:
>
> I think there are others that are interested, but it's pretty tough to
get
> anything done without breaking backwards compatibility.  Mark Hammond
> indicated he wants a usable buffer object for some asynchronous I/O 
> stuff, and the Numarray stuff addresses the shortcomings of the buffer 
> object by reinventing yet another wheel.
> 
> I've said this before, but I think the problem basically boils down to
the
> following - once you realize what the limitations of the buffer object 
> are, you realize that even if you fixed it, it isn't useful for what you 
> wanted to use it for.
>


--- Back to Guido van Rossum:
> 
> I read this as a recommendation to forget about returning strings.  Am
> I mistaken?
> 

Only if breaking backwards compatibility is an option.  I'd like to see
that happen, but I think that would take a pronouncement from someone in
authority.


--- More of Guido van Rossum:
>
> Also, I wish you'd submitted that PEP.  IMO the reason that nobody
> likes this topic is that there is much confusion about why we have
> buffer objects in the first place.  Any attempt at clarifying this
> (e.g. proposing separate byte arrays and buffer inspectors) would be
> welcome.
>

I'm glad to hear this.  I'll submit the PEP sometime in the next week.


Cheers,
    -Scott Gilbert




__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com