Mailman 3 PEP 3156 - Asynchronous IO Support Rebooted - Python-Dev

newer
Set close-on-exec flag by default...

PEP 3156 - Asynchronous IO Support Rebooted

older
Re: [Python-Dev] [Python-checkins]...

Yuriy Taraday

9 Jan 2013 9 Jan '13

2:14 a.m.

Hello. I've read the PEP and some things raise questions in my consciousness. Here they are. 1. Series of sock_ methods can be organized into a wrapper around sock object. This wrappers can then be saved and used later in async-aware code. This way code like: sock = socket(...) # later, e.g. in connect() yield from tulip.get_event_loop().sock_connect(sock, ...) # later, e.g. in read() data = yield from tulip.get_event_loop().sock_recv(sock, ...) will look like: sock = socket(...) async_sock = tulip.get_event_loop().wrap_socket(sock) # later, e.g. in connect() yield from async_sock.connect(...) # later, e.g. in read() data = yield from async_sock.recv(...) Interface looks cleaner while plain calls (if they ever needed) will be only 5 chars longer. 2. Not as great, but still possible to wrap fd in similar way to make interface simpler. Instead of: add_reader(fd, callback, *args) remove_reader(fd) We can do: wrap_fd(fd).reader = functools.partial(callback, *args) wrap_fd(fd).reader = None # or del wrap_fd(fd).reader 3. Why not use properties (or fields) instead of methods for cancelled, running and done in Future class? I think, it'll be easier to use since I expect such attributes to be accessed as properties. I see it as some javaism since in Java Future have getters for this fields but they are prefixed with 'is'. 4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"? 5. I think, protocol and transport methods' names are not easy or understanding enough: - write_eof() does not write anything but closes smth, should be close_writing or smth alike; - the same way eof_received() should become smth like receive_closed; - pause() and resume() work with reading only, so they should be suffixed (prefixed) with read(ing), like pause_reading(), resume_reading(). Kind regards, Yuriy.

Attachments:

attachment.htm (text/html — 2.8 KB)

Show replies by date

Benjamin Peterson

9 Jan 9 Jan

3:07 a.m.

2013/1/8 Yuriy Taraday :

...

4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

I expect that's a copy-and-paste error. exception() will return the exception if one occured. -- Regards, Benjamin

Guido van Rossum

3:49 a.m.

On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson wrote:

...

2013/1/8 Yuriy Taraday :

...
4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

I expect that's a copy-and-paste error. exception() will return the exception if one occured.

I don't see the typo. It is as Nick explained. -- --Guido van Rossum (python.org/~guido)

Benjamin Peterson

3:53 a.m.

2013/1/8 Guido van Rossum :

...

On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson wrote:

...
2013/1/8 Yuriy Taraday :

...
4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

I expect that's a copy-and-paste error. exception() will return the exception if one occured.

I don't see the typo. It is as Nick explained.

PEP 3156 says "exception(). Difference with PEP 3148: This has no timeout argument and does not wait; if the future is not yet done, it raises an exception." I assume it's not supposed to raise. -- Regards, Benjamin

Benjamin Peterson

4:02 a.m.

2013/1/8 Benjamin Peterson :

...

2013/1/8 Guido van Rossum :

...
On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson wrote:

...
2013/1/8 Yuriy Taraday :

...
4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

I expect that's a copy-and-paste error. exception() will return the exception if one occured.

I don't see the typo. It is as Nick explained.

PEP 3156 says "exception(). Difference with PEP 3148: This has no timeout argument and does not wait; if the future is not yet done, it raises an exception." I assume it's not supposed to raise.

Oh, I see. "it raises an exception" refers to the not-completed-eyt exception. Poor reading on my part; never mind. -- Regards, Benjamin

Guido van Rossum

4:06 a.m.

On Tue, Jan 8, 2013 at 6:53 PM, Benjamin Peterson wrote:

...

2013/1/8 Guido van Rossum :

...
On Tue, Jan 8, 2013 at 6:07 PM, Benjamin Peterson wrote:

...
2013/1/8 Yuriy Taraday :

...
4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

I expect that's a copy-and-paste error. exception() will return the exception if one occured.

I don't see the typo. It is as Nick explained.

PEP 3156 says "exception(). Difference with PEP 3148: This has no timeout argument and does not wait; if the future is not yet done, it raises an exception." I assume it's not supposed to raise.

No, actually, in that case it *does* raise an exception, because it means that the caller didn't understand the interface. It *returns* an exception object when the Future is done but the "result" is exceptional. But it *raises* when the Future is not done yet. -- --Guido van Rossum (python.org/~guido)

Nick Coghlan

3:31 a.m.

On Wed, Jan 9, 2013 at 11:14 AM, Yuriy Taraday wrote:

...

4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

The exception() method exists for the same reason that we support both "key in mapping" and raising KeyError from "mapping[key]": sometimes you want "Look Before You Leap", other times you want to let the exception fly. If you want the latter, just call .result() directly, if you want the former, check .exception() first. Regardless, the Future API isn't really being defined in PEP 3156, as it is mostly inheritied from the previously implemented PEP 3148 (http://www.python.org/dev/peps/pep-3148/#future-objects) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Yuriy Taraday

4:56 a.m.

On Wed, Jan 9, 2013 at 6:31 AM, Nick Coghlan wrote:

...

On Wed, Jan 9, 2013 at 11:14 AM, Yuriy Taraday wrote:

...
4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

The exception() method exists for the same reason that we support both "key in mapping" and raising KeyError from "mapping[key]": sometimes you want "Look Before You Leap", other times you want to let the exception fly. If you want the latter, just call .result() directly, if you want the former, check .exception() first.

Ok, I get it now. Thank you for clarifying.

...

Regardless, the Future API isn't really being defined in PEP 3156, as it is mostly inheritied from the previously implemented PEP 3148 (http://www.python.org/dev/peps/pep-3148/#future-objects)

Then #3 and #4 are about PEP 3148. Why was it done this way? Kind regards, Yuriy.

Guido van Rossum

5:31 a.m.

On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:

...

I've read the PEP and some things raise questions in my consciousness. Here they are.

Thanks!

...

1. Series of sock_ methods can be organized into a wrapper around sock object. This wrappers can then be saved and used later in async-aware code. This way code like:

sock = socket(...) # later, e.g. in connect() yield from tulip.get_event_loop().sock_connect(sock, ...) # later, e.g. in read() data = yield from tulip.get_event_loop().sock_recv(sock, ...)

will look like:

sock = socket(...) async_sock = tulip.get_event_loop().wrap_socket(sock) # later, e.g. in connect() yield from async_sock.connect(...) # later, e.g. in read() data = yield from async_sock.recv(...)

Interface looks cleaner while plain calls (if they ever needed) will be only 5 chars longer.

This is a semi-internal API that is mostly useful to Transport implementers, and there won't be many of those. So I prefer the API that has the fewest classes.

...

2. Not as great, but still possible to wrap fd in similar way to make interface simpler. Instead of:

add_reader(fd, callback, *args) remove_reader(fd)

We can do:

wrap_fd(fd).reader = functools.partial(callback, *args) wrap_fd(fd).reader = None # or del wrap_fd(fd).reader

Ditto.

...

3. Why not use properties (or fields) instead of methods for cancelled, running and done in Future class? I think, it'll be easier to use since I expect such attributes to be accessed as properties. I see it as some javaism since in Java Future have getters for this fields but they are prefixed with 'is'.

Too late, this is how PEP 3148 defined it. It was indeed inspired by Java Futures. However I would defend using methods here, since these are not all that cheap -- they have to acquire and release a lock.

...

4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

Because it is quite awkward to check for an exception if you have to catch it (4 lines instead of 1).

...

5. I think, protocol and transport methods' names are not easy or understanding enough: - write_eof() does not write anything but closes smth, should be close_writing or smth alike; - the same way eof_received() should become smth like receive_closed;

I am indeed struggling a bit with these names, but "writing an EOF" is actually how I think of this (maybe I am dating myself to the time of mag tapes though :-).

...

- pause() and resume() work with reading only, so they should be suffixed (prefixed) with read(ing), like pause_reading(), resume_reading().

Agreed. -- --Guido van Rossum (python.org/~guido)

Guido van Rossum

5:50 a.m.

On Tue, Jan 8, 2013 at 8:31 PM, Guido van Rossum wrote:

...

On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:

...
- pause() and resume() work with reading only, so they should be suffixed (prefixed) with read(ing), like pause_reading(), resume_reading().

Agreed.

I think I want to take that back. I think it is more common for a protocol to want to pause the transport (i.e. hold back data_received() calls) than it is for a transport to want to pause the protocol (i.e. hold back write() calls). So the more common method can have a shorter name. Also, pause_reading() is almost confusing, since the protocol's method is named data_received(), not read_data(). Also, there's no reason for the protocol to want to pause the *write* (send) actions of the transport -- if wanted to write less it should not have called write(). The reason to distinguish between the two modes of pausing is because it is sometimes useful to "stack" multiple protocols, and then a protocol in the middle of the stack acts as a transport to the protocol next to it (and vice versa). See the discussion on this list previously, e.g. http://mail.python.org/pipermail/python-ideas/2013-January/018522.html (search for the keyword "stack" in this long message to find the relevant section). -- --Guido van Rossum (python.org/~guido)

Yuriy Taraday

11:45 a.m.

On Wed, Jan 9, 2013 at 8:50 AM, Guido van Rossum wrote:

...

On Tue, Jan 8, 2013 at 8:31 PM, Guido van Rossum wrote:

...
On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:

...
- pause() and resume() work with reading only, so they should be suffixed (prefixed) with read(ing), like pause_reading(), resume_reading().

Agreed.

I think I want to take that back. I think it is more common for a protocol to want to pause the transport (i.e. hold back data_received() calls) than it is for a transport to want to pause the protocol (i.e. hold back write() calls). So the more common method can have a shorter name. Also, pause_reading() is almost confusing, since the protocol's method is named data_received(), not read_data(). Also, there's no reason for the protocol to want to pause the *write* (send) actions of the transport -- if wanted to write less it should not have called write(). The reason to distinguish between the two modes of pausing is because it is sometimes useful to "stack" multiple protocols, and then a protocol in the middle of the stack acts as a transport to the protocol next to it (and vice versa). See the discussion on this list previously, e.g. http://mail.python.org/pipermail/python-ideas/2013-January/018522.html (search for the keyword "stack" in this long message to find the relevant section).

I totally agree with protocol/transport stacking, anyone should be able to do some ugly thing like FTP over SSL over SOCKS over SSL over HTTP (j/k). Just take a look at what you can do with netgraph in *BSD (anything over anything with any number of layers). But still we shouldn't sacrifice ease of understanding (both docs and code) for couple extra chars (10 actually). Yes, 'reading' is misleading, pause_receiving and resume_receiving are better. -- Kind regards, Yuriy.

Yuriy Taraday

6:02 a.m.

On Wed, Jan 9, 2013 at 8:31 AM, Guido van Rossum wrote:

...

On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:

...
I've read the PEP and some things raise questions in my consciousness. Here they are.

Thanks!

...
1. Series of sock_ methods can be organized into a wrapper around sock object. This wrappers can then be saved and used later in async-aware code.

This is a semi-internal API that is mostly useful to Transport implementers, and there won't be many of those. So I prefer the API that has the fewest classes.

...
2. Not as great, but still possible to wrap fd in similar way to make interface simpler.

Ditto.

Ok, I see. Should transports be bound to event loop on creation? I wonder, what would happen if someone changes current event loop between these calls.

...

...
3. Why not use properties (or fields) instead of methods for cancelled, running and done in Future class? I think, it'll be easier to use since I expect such attributes to be accessed as properties. I see it as some javaism since in Java Future have getters for this fields but they are prefixed with 'is'.

Too late, this is how PEP 3148 defined it. It was indeed inspired by Java Futures. However I would defend using methods here, since these are not all that cheap -- they have to acquire and release a lock.

...

...
4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

Because it is quite awkward to check for an exception if you have to catch it (4 lines instead of 1).

5. I think, protocol and transport methods' names are not easy or

...
understanding enough: - write_eof() does not write anything but closes smth, should be close_writing or smth alike; - the same way eof_received() should become smth like receive_closed;

I am indeed struggling a bit with these names, but "writing an EOF" is actually how I think of this (maybe I am dating myself to the time of mag tapes though :-).

I never saw a computer working with a tape, but it's clear to me what does

I understand why it should be a method, but still if it's a getter, it should have either get_ or is_ prefix. Are there any way to change this with 'Final' PEP? they do. I've just imagined the amount of words I'll have to say to students about EOFs instead of simple "it closes our end of one half of a socket".

...

- pause() and resume() work with reading only, so they should be suffixed

...
(prefixed) with read(ing), like pause_reading(), resume_reading().

Agreed.

-- --Guido van Rossum (python.org/~guido)

-- Kind regards, Yuriy.

Guido van Rossum

6:14 a.m.

On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday wrote:

...

On Wed, Jan 9, 2013 at 8:31 AM, Guido van Rossum wrote:

...
On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote:

...
1. Series of sock_ methods can be organized into a wrapper around sock object. This wrappers can then be saved and used later in async-aware code.

This is a semi-internal API that is mostly useful to Transport implementers, and there won't be many of those. So I prefer the API that has the fewest classes.

...
2. Not as great, but still possible to wrap fd in similar way to make interface simpler.

Ditto.

Ok, I see. Should transports be bound to event loop on creation? I wonder, what would happen if someone changes current event loop between these calls.

Yes, this is what the transport implementation does.

...

...
...
3. Why not use properties (or fields) instead of methods for cancelled, running and done in Future class? I think, it'll be easier to use since I expect such attributes to be accessed as properties. I see it as some javaism since in Java Future have getters for this fields but they are prefixed with 'is'.

Too late, this is how PEP 3148 defined it. It was indeed inspired by Java Futures. However I would defend using methods here, since these are not all that cheap -- they have to acquire and release a lock.

I understand why it should be a method, but still if it's a getter, it should have either get_ or is_ prefix.

Why? That's not a universal coding standard. The names seem clear enough to me.

...

Are there any way to change this with 'Final' PEP?

No, the concurrent.futures package has been released (I forget if it was Python 3.2 or 3.3) and we're bound to backwards compatibility. Also I really don't think it's a big deal at all.

...

...
...
4. Why separate exception() from result() for Future class? It does the same as result() but with different interface (return instead of raise). Doesn't this violate the rule "There should be one obvious way to do it"?

Because it is quite awkward to check for an exception if you have to catch it (4 lines instead of 1).

...
5. I think, protocol and transport methods' names are not easy or understanding enough: - write_eof() does not write anything but closes smth, should be close_writing or smth alike; - the same way eof_received() should become smth like receive_closed;

I am indeed struggling a bit with these names, but "writing an EOF" is actually how I think of this (maybe I am dating myself to the time of mag tapes though :-).

I never saw a computer working with a tape, but it's clear to me what does they do. I've just imagined the amount of words I'll have to say to students about EOFs instead of simple "it closes our end of one half of a socket".

But which half? A socket is two independent streams, one in each direction. Twisted uses half_close() for this concept but unless you already know what this is for you are left wondering which half. Which is why I like using 'write' in the name. -- --Guido van Rossum (python.org/~guido)

Yuriy Taraday

6:26 a.m.

On Wed, Jan 9, 2013 at 9:14 AM, Guido van Rossum wrote:

...

On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday wrote:

...
Should transports be bound to event loop on creation? I wonder, what would happen if someone changes current event loop between these calls.

Yes, this is what the transport implementation does.

But in theory every sock_ call is independent and returns Future bound to current event loop. So if one change event loop with active transport, nothing bad should happen. Or I'm missing something.

...

...
I understand why it should be a method, but still if it's a getter, it should have either get_ or is_ prefix.

Why? That's not a universal coding standard. The names seem clear enough to me.

When I see (in autocompletion, for example) or remember name like "running", it triggers thought that it's a field. When I remember smth like is_running, it definitely associates with method.

...

...
Are there any way to change this with 'Final' PEP?

No, the concurrent.futures package has been released (I forget if it was Python 3.2 or 3.3) and we're bound to backwards compatibility. Also I really don't think it's a big deal at all.

Yes, not a big deal.

...

...
...
...
5. I think, protocol and transport methods' names are not easy or understanding enough: - write_eof() does not write anything but closes smth, should be close_writing or smth alike; - the same way eof_received() should become smth like receive_closed;

I am indeed struggling a bit with these names, but "writing an EOF" is actually how I think of this (maybe I am dating myself to the time of mag tapes though :-).

I never saw a computer working with a tape, but it's clear to me what does they do. I've just imagined the amount of words I'll have to say to students about EOFs instead of simple "it closes our end of one half of a socket".

But which half? A socket is two independent streams, one in each direction. Twisted uses half_close() for this concept but unless you already know what this is for you are left wondering which half. Which is why I like using 'write' in the name.

Yes, 'write' part is good, I should mention it. I meant to say that I won't need to explain that there were days when we had to handle a special marker at the end of file. -- Kind regards, Yuriy.

Stephen J. Turnbull

6:42 a.m.

New subject: [Python-ideas] PEP 3156 - Asynchronous IO Support Rebooted

Is this thread really ready to migrate to python-dev when we're still bikeshedding method names? Yuriy Taraday writes:

...

...
But which half? A socket is two independent streams, one in each direction. Twisted uses half_close() for this concept but unless you already know what this is for you are left wondering which half. Which is why I like using 'write' in the name.

Yes, 'write' part is good, I should mention it. I meant to say that I won't need to explain that there were days when we had to handle a special marker at the end of file.

Mystery is good for students.<wink/> Getting serious, "close_writer" occured to me as a possibility.

Jasper St. Pierre

6:59 a.m.

New subject: [Python-ideas] PEP 3156 - Asynchronous IO Support Rebooted

Well, if we're at the "bikeshedding about names" stage, that means that no serious issues with the proposal are left. So it's a sign of progress. On Wed, Jan 9, 2013 at 12:42 AM, Stephen J. Turnbull wrote:

...

Is this thread really ready to migrate to python-dev when we're still bikeshedding method names?

Yuriy Taraday writes:

...
...
But which half? A socket is two independent streams, one in each direction. Twisted uses half_close() for this concept but unless you already know what this is for you are left wondering which half. Which is why I like using 'write' in the name.

Yes, 'write' part is good, I should mention it. I meant to say that I won't need to explain that there were days when we had to handle a special marker at the end of file.

Mystery is good for students.<wink/>

Getting serious, "close_writer" occured to me as a possibility. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Jasper

Guido van Rossum

7:02 a.m.

On Tue, Jan 8, 2013 at 9:26 PM, Yuriy Taraday wrote:

...

On Wed, Jan 9, 2013 at 9:14 AM, Guido van Rossum wrote:

...
On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday wrote:

...
Should transports be bound to event loop on creation? I wonder, what would happen if someone changes current event loop between these calls.

Yes, this is what the transport implementation does.

But in theory every sock_ call is independent and returns Future bound to current event loop.

It is bound to the event loop whose sock_<call>() method you called.

...

So if one change event loop with active transport, nothing bad should happen. Or I'm missing something.

Changing event loops in the middle of event processing is not a common (or even useful) pattern. You start the event loop and then leave it alone.

...

...
...
I understand why it should be a method, but still if it's a getter, it should have either get_ or is_ prefix.

Why? That's not a universal coding standard. The names seem clear enough to me.

When I see (in autocompletion, for example) or remember name like "running", it triggers thought that it's a field. When I remember smth like is_running, it definitely associates with method.

That must pretty specific to your personal experience.

...

...
...
Are there any way to change this with 'Final' PEP?

No, the concurrent.futures package has been released (I forget if it was Python 3.2 or 3.3) and we're bound to backwards compatibility. Also I really don't think it's a big deal at all.

Yes, not a big deal.

...
...
...
...
5. I think, protocol and transport methods' names are not easy or understanding enough: - write_eof() does not write anything but closes smth, should be close_writing or smth alike; - the same way eof_received() should become smth like receive_closed;

I am indeed struggling a bit with these names, but "writing an EOF" is actually how I think of this (maybe I am dating myself to the time of mag tapes though :-).

I never saw a computer working with a tape, but it's clear to me what does they do. I've just imagined the amount of words I'll have to say to students about EOFs instead of simple "it closes our end of one half of a socket".

But which half? A socket is two independent streams, one in each direction. Twisted uses half_close() for this concept but unless you already know what this is for you are left wondering which half. Which is why I like using 'write' in the name.

Yes, 'write' part is good, I should mention it. I meant to say that I won't need to explain that there were days when we had to handle a special marker at the end of file.

But even today you have to mark the end somehow, to distinguish it from "not done yet, more could be coming". The equivalent is typing ^D into a UNIX terminal (or ^Z on Windows). -- --Guido van Rossum (python.org/~guido)

Yuriy Taraday

11:55 a.m.

On Wed, Jan 9, 2013 at 10:02 AM, Guido van Rossum wrote:

...

Changing event loops in the middle of event processing is not a common (or even useful) pattern. You start the event loop and then leave it alone.

Yes. It was not-so-great morning idea.

...

Yes, 'write' part is good, I should mention it. I meant to say that I won't

...
need to explain that there were days when we had to handle a special marker at the end of file.

But even today you have to mark the end somehow, to distinguish it from "not done yet, more could be coming". The equivalent is typing ^D into a UNIX terminal (or ^Z on Windows).

My interns told me that they remember EOF as special object only from high school when they had to study Pascal. I guess, in 5 years students won't understand how one can write an EOF. (and schools will finally replace Pascal with Python) -- Kind regards, Yuriy.

Nick Coghlan

12:06 p.m.

New subject: [Python-ideas] PEP 3156 - Asynchronous IO Support Rebooted

On Wed, Jan 9, 2013 at 8:55 PM, Yuriy Taraday wrote:

...

My interns told me that they remember EOF as special object only from high school when they had to study Pascal. I guess, in 5 years students won't understand how one can write an EOF. (and schools will finally replace Pascal with Python)

Python really doesn't try to avoid the concept of an End-of-file marker. ================ $ python3 Python 3.2.3 (default, Jun 8 2012, 05:36:09) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...
...
quit Use quit() or Ctrl-D (i.e. EOF) to exit import io print(io.FileIO.read.__doc__) read(size: int) -> bytes. read at most size bytes, returned as bytes.

Only makes one system call, so less data may be returned than requested In non-blocking mode, returns None if no data is available. On end-of-file, returns ''. ================ Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Glyph

10:30 a.m.

On Jan 8, 2013, at 9:14 PM, Guido van Rossum wrote:

...

But which half? A socket is two independent streams, one in each direction. Twisted uses half_close() for this concept but unless you already know what this is for you are left wondering which half. Which is why I like using 'write' in the name.

I should add, if you don't already know what this means you really shouldn't be trying to do it ;-). -glyph

Dustin J. Mitchell

12 Jan 12 Jan

4:03 p.m.

New subject: [Python-ideas] PEP 3156 - Asynchronous IO Support Rebooted

On Wed, Jan 9, 2013 at 12:14 AM, Guido van Rossum wrote:

...

But which half? A socket is two independent streams, one in each direction. Twisted uses half_close() for this concept but unless you already know what this is for you are left wondering which half. Which is why I like using 'write' in the name.

FWIW, "half-closed" is, IMHO, a well-known term. It's not just a Twisted thing. Either name is better than "shutdown"! Dustin

Antoine Pitrou

9 Jan 9 Jan

10:39 a.m.

Hi Yuriy, For the record, it isn't necessary to cross-post. python-ideas is the place for discussing this, and most interested people will be subscribed to both python-ideas and python-dev, and therefore they get duplicate messages. Regards Antoine. Le Wed, 9 Jan 2013 05:14:02 +0400, Yuriy Taraday a écrit :

...

Hello.

I've read the PEP and some things raise questions in my consciousness. Here they are. [snip]

Yuriy Taraday

noon

On Wed, Jan 9, 2013 at 1:39 PM, Antoine Pitrou wrote:

...

Hi Yuriy,

For the record, it isn't necessary to cross-post. python-ideas is the place for discussing this, and most interested people will be subscribed to both python-ideas and python-dev, and therefore they get duplicate messages.

Oh, sorry. I just found this thread in both MLs, so decided to send it to both. This will be my last email (for now) on this topic at python-dev. -- Kind regards, Yuriy.

4121

Age (days ago)

4124

Last active (days ago)

List overview

Download

22 comments

9 participants

participants (9)

Antoine Pitrou
Benjamin Peterson
Dustin J. Mitchell
Glyph
Guido van Rossum
Jasper St. Pierre
Nick Coghlan
Stephen J. Turnbull
Yuriy Taraday

PEP 3156 - Asynchronous IO Support Rebooted

tags

participants (9)