Hello, On Mon, 6 Apr 2020 09:41:46 -0700 Christopher Barker <python...@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:pmis...@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UGTNAHT2TGZ6AYI7ZNTQ3UGOPSPPDXH2/ Code of Conduct: http://python.org/psf/codeofconduct/
