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

[Glyph]

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.

-glyph