On Fri, Jan 4, 2013 at 8:19 PM, Glyph <gl...@twistedmatrix.com> wrote: > > On Jan 4, 2013, at 3:56 PM, Guido van Rossum <gu...@python.org> wrote: > >> On Mon, Dec 24, 2012 at 2:58 PM, Glyph <gl...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
