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/

Reply via email to