It seems we're still in the same boat. It would be saner to change buffer slices to return buffer objects, except for backward compatibility. I was hoping to hear from someone who uses buffer objects and knows that this would break his code. Scott apparently doesn't have this problem with his own code, so his opinion doesn't help. :-( Raymond's change still breaks compatibility, though, for slices without begin and end points. So we have a contradiction: out of fear of breaking compatibility, we make a change that breaks compatibility. Maybe we should do the same with the buffer object as we did with xrange(), and plan to remove all functionality that we aren't sure is useful? In 2.3, we would have to maintain compatibility but we could warn about features that will go away; in 2.4, we could remove unwanted features. Maybe the name 'buffer' suggests false expectations? It's not a buffer, it's an alias for a memory area. Maybe we should do something stronger, and deprecate the buffer type altogether. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4