[EMAIL PROTECTED] said:
> (BTW, I actually think this sort of functionality should be part of
> the OS kernel, with event-driven programs and libraries being so
> important nowadays. Sort of like being able to define signal handlers
> for file descriptors instead of having a small, fixed number of
oops -- this was meant for python-dev, not python-3000.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
On 6/4/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> can we please delay the import until it's actually needed? i.e.,
> until after some logging option is enabled?
I have asked her to make this change.
I don't like the extra conditional dance it causes, but I agree that
not wanting to log is a
tomer filiba wrote:
> yes, but +=/-= can be overriden to provide "efficient seeking". and, just
> thought about it: just like negative indexes of sequences, negative positions
> should be relative to the end of the stream. for example:
>
> f.position = 4 # absolute -- seek(4, "start")
> f.pos
tomer filiba wrote:
> okay, i give up on read(n) returning n bytes.
An idea I had about this some time ago was that read()
could be callable with two arguments:
f.read(min_bytes, max_bytes)
The two variations we're considering would then be special
cases of this:
f.read(0, num_bytes)
tomer filiba wrote:
> I wrote:
> > My current opinion on select-like functionality is
> > that you shouldn't need to import a module for it at
> > all. Rather, you should be able to attach a callback
> > directly to a stream. Then there just needs to be
> > a wait_for_something_to_happen() fun
> I don't believe it would "[destroy] the very foundations of python"
> (unicode is not the very foundation of Python, and it wouldn't destroy
> unicode, only change its comparison semantics), but I do believe it
> "[lacks] a proper rationale"
no, it would break the basic rules of comparisson. all
hey
> One thing I would like to raise is the issue of KeyboardInterrupt. I find
> very inconvenient that a normal application doing a very simple blocking
> read from a socket can't be interrupted by a CTRL+C sequence. Usually, what
> I do is to setup a timeout on the sockets (eg. 0.4 seconds) and
"tomer filiba" <[EMAIL PROTECTED]> wrote:
>
> > > 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.
>
> if it runs on windows, linux, *bsd, solaris, it's virtually platform
> i
tomer filiba wrote:
> some time ago i wrote this huge post about stackable IO and the
> need for a new socket module. i've made some progress with
> those, and i'd like to receive feedback.
>
> * a working alpha version of the new socket module (sock2) is
> available for testing and tweaking with
> > 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.
if it runs on windows, linux, *bsd, solaris, it's virtually platform
independent.
i don't consider the nokia N60 or whatever the name was
> 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 be dirt simple.
it's a convenience method. instead of doing it yourself everytime,readavail() returns all the available data in the socket's buffers.the basi
Tomer writes:
> well is func((1,2,3)) the same as func(1,2,3)? no.
> so why should container[1, 2, 3] be the same as container[(1,2,3)]?
> you say it's a feature. is it intentionally *ambiguous*?
>
> what you'd want in that case is
> t = (1, 2, 3)
> container[*t]
> or something like that.
>
13 matches
Mail list logo
