--- 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
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
get 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