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. -glyph _______________________________________________ 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
