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()? (Given that the transport and protocol classes are different for datagrams, I suppose the create*() methods should also be different, rather than just having a type={SOCK_STREAM,SOCK_DATAGRAM} flag. But I can figure that out for myself. The naming and exact APIs for the client and server transport creation methods are in flux anyway.) -- --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