[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

[Guido van Rossum]

On Fri, Jan 4, 2013 at 8:19 PM, Glyph <glyph at twistedmatrix.com> wrote:
>
> On Jan 4, 2013, at 3:56 PM, Guido van Rossum <guido at python.org> wrote:
>
>> On Mon, Dec 24, 2012 at 2:58 PM, Glyph <glyph at twistedmatrix.com> wrote:
>>> In my humble (but entirely, verifiably correct) opinion, thinking of this as
>>> a "default" is propagating a design error in the BSD sockets API.  Datagram
>>> and stream sockets have radically different semantics.  In Twisted,
>>> "dataReceived" and "datagramReceived" are different methods for a good
>>> reason.  Again, it's very very easy to fall into the trap of thinking that a
>>> TCP segment is a datagram and writing all your application code as if it
>>> were.  After all, it probably works over localhost most of the time!  This
>>> difference in semantics mirrored by a difference in method naming has helped
>>> quite a few people grok the distinction between streaming and datagrams over
>>> the years; I think it would be a good idea if Tulip followed suit.
>>
>> Suppose PEP 3156 / Tulip uses data_received() for streams and
>> datagram_received() for datagram protocols (which seems reasonable
>> enough), what API should a datagram transport have for sending
>> datagrams? write_datagram() and write_datagram_list()?
>
> Twisted just have a different method called write() which has a different signature (data, address).  Probably write_datagram is better.  Why write_datagram_list though?  Twisted's writeSequence is there to provide the (eventual) opportunity to optimize by writev; since datagrams are always sent one at a time anyway, write_datagram_list would seem to be a very minor optimization.

That makes sense (you can see I haven't tried to use UDP in a long time :-).

Should write_datagram() perhaps return a future? Or is there still a
use case for buffering datagrams?

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