Hello, On Mon, 6 Apr 2020 09:41:46 -0700 Christopher Barker <pythonchb@gmail.com> wrote:
Sorry, this has been sitting in my drafts for a while, and maybe this conversation is over. But since I wrote it, I figured I might as well post it.
I appreciate it, and it's actually my desired intention to not leave this thread abruptly cut (like 2006's thread), but share further "news", discussion, and argumentation. In this regard, I got enough useful suggestions, but realizing them definitely takes time and effort, hence delays with replies. []
So, stream and buffer protocols are very important, powerful, and deep notion in Python.
streams, yes (though even though the docs and CS-educated folks use the word Stream, in the broader community, we usually think more in terms of "File Like Object" -- at least those of us that have been around for a long time.
I would humbly disagree. "Stream" is used in broader community, and "file-like object" - in narrow Python community.
As for "buffer", if you search the docs, you see that the word is used to describe the Buffer Protocol, which is a whole different concept.
I see, it's whole different concept for you. But as I mentioned, they're the same concept for me - both stream and buffer *are* protocols. And that's based on my desire to define Python as a generic programming language, based on a few consistent and powerful concepts. []
All that is a long way of saying that most folks at not thinking in terms of buffers
That's exactly what I seek to change - people to stop think in terms of adhoc notions and patterns, and start to think in terms of generic concepts (which are still efficient implementation-wise).
It's my idea that BytesIO/StringIO is the closest what Python has to
this buffer/stream "cross-object", and actually, it is already does enough to be *the* cross-object.
sure -- I'll agree with that.
I appreciate that. We'll never agree in other things, and that's the motivation for my replies - to pinpoint the roots of the disagreement, to see why our think is tangential. (Of course, I do that to find people with similar, not dissimilar, ideas.)
BytesIO
In fact, the entire reason it exists is to be a file-like object (i.e. the stream API).
As I said, no problem - we'll redefine the reason of its existance to be a cross-implementation of both stream and buffer APIs.
But the fact that BytesIO can do different things is exactly the
motivation for proposing to add another operator, +=, that's not going to change the status quo of "does different things" that much. And the operator += being added isn't random - it's buffer's append method,
well, no. It's Sequence's extend() method
Nice note about subtyping relation. So, indeed, "buffer" is a "sequence of bytes" (*). So, you'll keep thinking of it's as a superclass method, and I as a subclass method, and we'll never agree, but fortunately, we're thinking about absolutely the same. (*) Or other real-world types like int32, uint64, etc. []
Which is why I suggested that the way to get what you want would be a mutable string, rather than a single, out of place, addition to StringIO.
As argued, it's very in-place addition.
And a StringBuilder class would be another way.
StringBuilder would be just subset of functionality of StringIO, and would be hard to survive Occam's razor. (Mine is sharp to cut it off right away.)
However: as it happens strings are unique in Python: I *think* they are the only built in "ABC" with only one implementation (that is, not only type with no ABC :-) ): they are not duck-typed at all
And that's absolutely great! They thus allow for efficient implementation, be it interpreted, or compiled AOT or JIT. That's why you'd never hear a proposal for mutable strings from me. (And when I need mutable thingy, it's already there - mutable byte buffer aka bytearray. But that's not the type optimized for appending, BytesIO by definition is. So, that's what gets "sequence" append method.) [] -- Best regards, Paul mailto:pmiscml@gmail.com