I've been slowly working on PEP 3101, specifically fleshing out the
details, and there's a couple of issues that I wanted to run by the
group mind here.
Originally, I decided to punt on the issue of field conversion
specifiers (i.e. %2.2s etc.) and simply say that they were unchanged
from the
tomer filiba <[EMAIL PROTECTED]> wrote:
>> 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 time
Greg Ewing wrote:
> 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
> case
Greg Ewing wrote:
> 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 -
On 6-jun-2006, at 11:51, Nick Coghlan wrote:
> Greg Ewing wrote:
>> 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 va
Talin wrote:
> So I decided to sit down and rethink the whole conversion specifier
> system. I looked at the docs for the '%' operator, and some other
> languages, and here is what I came up with (this is an excerpt from the
> revised PEP.)
Generally nice, but I'd format the writeup a bit diffe
Greg Ewing <[EMAIL PROTECTED]> writes:
> The two variations we're considering would then be special
> cases of this:
>
>f.read(0, num_bytes) # current read() behaviour
>
>f.read(num_bytes, num_bytes) # record-oriented read() behaviour
Current read() reads at least 1 byte.
--
Talin writes:
> So I decided to sit down and rethink the whole conversion specifier
> system.
+1: good idea!
Nick Coghlan writes:
> Generally nice, but I'd format the writeup a bit differently (see below) and
> reorder the elements so that an arbitrary character can be supplied as the
> fill char
Jason Lunz wrote:
> [EMAIL PROTECTED] said:
>
> > Sort of like being able to define signal handlers
> > for file descriptors instead of having a small, fixed number of
> > signals.)
>
> That's supported on linux, but I don't
> know how portable it is. See F_SETSIG in fcntl(2), and sigaction(2).
Ronald Oussoren wrote:
> I'm slighly worried about this thread. Async I/O and "read exactly N
> bytes" don't really match up. I don't know about the other mechanisms,
> but at least with select and poll when the system says you can read
> from a file descriptor you're only guaranteed that on
Marcin 'Qrczak' Kowalczyk wrote:
> Greg Ewing <[EMAIL PROTECTED]> writes:
>> f.read(0, num_bytes) # current read() behaviour
>
> Current read() reads at least 1 byte.
Except if EOF is reached before getting any bytes.
In that case, if min_bytes is 0, the call simply
returns 0 bytes.
On Wed, Jun 07, 2006 at 01:20:02AM +1200, Greg Ewing wrote:
> It's not quite the same thing, anyway. What I had in mind was
> attaching the handler itself directly to the file descriptor, rather
> than going through a signal number. That way, different piece of code
> can use the mechanism independ
> Here is a list of the conversion types that are currently supported by
> the % operator. First thing you notice is an eerie similarity between
> this and the documentation for 'sprintf'. :)
Yes. This is (or was) a significant advantage to the system. Many
people already had mastered the C/C+
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Ronald Oussoren wrote:
>
> > I'm slighly worried about this thread. Async I/O and "read exactly N
> > bytes" don't really match up. I don't know about the other mechanisms,
> > but at least with select and poll when the system says you can read
> >
WaitForMultipleObjects doesnt work on sockets of files...
On 6/6/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> tomer filiba <[EMAIL PROTECTED]> wrote:
>
> >> One thing I would like to raise is the issue of KeyboardInterrupt. I
> >> find very inconvenient that a normal application doing a very sim
Nick Coghlan wrote:
> Talin wrote:
>
>> So I decided to sit down and rethink the whole conversion specifier
>> system. I looked at the docs for the '%' operator, and some other
>> languages, and here is what I came up with (this is an excerpt from
>> the revised PEP.)
>
>
> Generally nice, b
> On 6/6/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>> tomer filiba <[EMAIL PROTECTED]> wrote:
>>
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 interrupt
> You can use WSAAsyncSelect to activate message notification for socket events,
> and then wait with MsgWaitForMultipleObjects.
i remember reading in the winsock manual that these two methods are slower,
and not suitable for servers.
> It *is* possible to have a single point of event dispatching
tomer filiba <[EMAIL PROTECTED]> wrote:
>> You can use WSAAsyncSelect to activate message notification for
>> socket events, and then wait with MsgWaitForMultipleObjects.
>
> i remember reading in the winsock manual that these two methods are
> slower, and not suitable for servers.
Might be FUD o
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> tomer filiba <[EMAIL PROTECTED]> wrote:
>
> >> You can use WSAAsyncSelect to activate message notification for
> >> socket events, and then wait with MsgWaitForMultipleObjects.
> >
> > i remember reading in the winsock manual that these two methods are
the old thread was getting too nested, so i made a summary
of the key points raised during that discussion:
http://sebulba.wikispaces.com/project+iostack+todo
is there anything else i missed? any more comments to add
to the summary?
i'll have time to incorporate part of these issues on the weeke
"tomer filiba" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> thanks for all the comments so far, they have already proved
> very helpful and furtile.
I think you meant fertile (as opposed to futile ;-)
___
Python-3000 mailing list
Py
tomer filiba <[EMAIL PROTECTED]> wrote:
> the old thread was getting too nested, so i made a summary
> of the key points raised during that discussion:
>
> http://sebulba.wikispaces.com/project+iostack+todo
>
> is there anything else i missed? any more comments to add
> to the summary?
About thi
tomer filiba <[EMAIL PROTECTED]> wrote:
> the old thread was getting too nested, so i made a summary
> of the key points raised during that discussion:
>
> http://sebulba.wikispaces.com/project+iostack+todo
>
> is there anything else i missed? any more comments to add
> to the summary?
About thi
Jason Lunz wrote:
> I imagine if one were going to do this, that would be hidden in the
> stdlib.
Having it in libc would be okay. The important thing
is that the implementation should allow your handlers
to get called even if some library call is blocked
and not being cooperative.
--
Greg
_
Giovanni Bajo wrote:
> About this part: "properties raising IOError", I would like to remember that
> Guido pronounced on The Way properties should be used in Py3k. Part of the
> pronouncement was that reading/writing properties should never have
> side-effects.
That's meaningless without a defi
"tomer filiba" <[EMAIL PROTECTED]> wrote:
>
> the old thread was getting too nested, so i made a summary
> of the key points raised during that discussion:
>
> http://sebulba.wikispaces.com/project+iostack+todo
>
> is there anything else i missed? any more comments to add
> to the summary?
* "
Nick Coghlan wrote:
> Talin wrote:
>
>> So I decided to sit down and rethink the whole conversion specifier
>> system. I looked at the docs for the '%' operator, and some other
>> languages, and here is what I came up with (this is an excerpt from
>> the revised PEP.)
>
>
> Generally nice, bu
28 matches
Mail list logo
