tomer filiba wrote:
> NetworkStreams have a readavail() method, which reads all the available
> in-queue data, as well as a may_read and a may_write properties
I'm -1 on having multiple kinds of read methods which
are available only on some kinds of streams. The
basic interface of a stream should
Nick Coghlan <[EMAIL PROTECTED]> wrote:
[snip]
> Any operations that may touch the filesystem or network shouldn't be
> properties - attribute access should never raise IOError (this is a guideline
> that came out of the Path discussion). (e.g. the 'position' property is
> probably a bad idea,
"tomer filiba" <[EMAIL PROTECTED]> wrote:
[snip]
> > - interaction with (replacement of?) the select module
>
> well, it's too hard to design for a nonexisting module. select is all there
> is that's platform independent.
It is /relatively/ platform independent.
> random idea:
> * select is vir
you certainly have good points there.
i'll start with the easy ones:
>Some things that don't appear to have been considered in the iostack
design yet:
> - non-blocking IO and timeouts (e.g. on NetworkStreams)
NetworkStreams have a readavail() method, which reads all the available
in-queue data, a
"Ronald Oussoren" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I'm -lots on a package named "misc". That's really poor naming,
>almost as bad as "util". Misc is the "we don't know what to do with
>these"-category and completely unobvious for anyone that doesn't
>already know where
On 2-jun-2006, at 20:53, Terry Reedy wrote:
"Aaron Bingham" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[me]
For the latter (2 above), I think those who want such mostly
agree in
principle on a mostly two-level hierarchy with about 10-20 short
names
for
the top-level, usi
