Cameron Simpson wrote:
But people not using threads, or at any rate not dedicating a thread to the reading task, don't have such luxury.
But without a dedicated thread you need to use select() or poll(), and then buffering causes other headaches.
Are we disputing the utility of being able to ask "how much might I read/peek without blocking"?
I'm saying that I don't see how I would make use of such a thing, so I probably wouldn't mind if it didn't exist.
Or disputing the purpose of peek, which feels to me like it should/might ask that question, but doesn't.
I think what I'm saying is that there are two distinct use cases being talked about for a peek-like operation, and different people seem to have different ideas on which one should be mapped to the name "peek". So perhaps they should both be given more-explicit names.
It's perfectly possible, even reasonable, to avoid talking about the buffer at all. I'd be happy not to mention the buffer.
Even if you don't mention it explicitly, its existence shows through in the fact that there is an arbitrary limit on the amount you can peek ahead, and that limit needs to be documented so that people can write correct programs. This is true of both kinds of peeking, so I concede that they both break the abstraction. However I think the non-blocking peek breaks it more than the blocking one, because it also brings non-deterministic behaviour. -- Greg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
