On Sat, Jan 4, 2014 at 10:11 PM, Glyph <[email protected]> wrote: > Twisted's syntax is actually pretty bad [...]
Noted. > "connected UDP" is a strange beast, and it doesn't make UDP a connected > protocol; there's still no connection state machine, no way to tell if a > particular session is connected or disconnected. Technically, in the Tulip implementation it corresponds to whether the private variable transport._address is None or not. Of course I may not understand what you mean by "session" in this context. :-) >>> FWIW: https://twistedmatrix.com/documents/current/core/howto/udp.html#auto3 >>> >>> Finally: yes, syntactically, there is nothing which would distinguish an >>> ordered, reliable datagram interface from and unordered, unreliable datagram >>> interface (at least a connected one). >>> >>> Mmh, but shouldn't the interface _identity_ also express semantics? >> >> That seems an idea from Twisted. I don't want to go that way. I prefer >> giving the transport object an inquiry method if necessary; that's how >> asyncio does it for the capability to use write_eof() (which works for >> TCP but not for SSL/TLS). > > The principle that we use type-names to identify discrete sets of behavior is > an ideal that Twisted strives to adhere to, but it seems like a pretty basic > idea about type systems, not an idea we came up with. ("We use types for > nouns" in the words of Nathaniel Manista & Augie Fackler, both of whom are > very much not associated with Twisted ;-).) It's just having a consistent > way to talk about sets of methods and attributes and stuff. Isn't this the > whole reason that ABCMeta.register exists, so you can use ABCs in this way? > Then the inquiry method is always consistent, 'isinstance'. Hm. I really don't like using isinstance() for this particular set of purposes (checking if a datagram transport is reliable or not, or checking whether it is connected or not). I fear that there would be a proliferation of little interface classes that would be more confusing than enlightening -- in particular, whenever you mention something starting with I-something when talking about Twisted I usually feel more confused than enlightened. >>> If I get a transport, and want to adjust behavior according to whether the >>> transport is unreliable, even today I am not supposed to do that >>> via isinstance(transport, DatagramTransport), since DatagramTransport >>> doesn't imply any semantics, but only specifies a programmatic interface (on >>> a syntactical level)? >> >> You're already writing your protocol code specific to either a >> datagram or a stream transport, because the protocol API is >> (intentionally) different. So there's never a question about which >> kind of transport you have. > > I think that the point that Tobias was trying to make here is that if you > have some generic string-syntax way of generating a transport (like > endpoints) and the user can enter any transport-type they want, how does an > application say "I am only going to work over a reliable+ordered transport". > In Twisted (and in Zope) there's a pattern of using a zope Interface or a > python type object to identify the required semantics (as he pointed out > above). Which I specifically don't like (as I pointed out above :-). I read between the lines of the Twisted endpoints docs that they don't support anything besides streams. I suspect that the use case for the inquiry discussed here is purely theoretical. > In the case of endpoints, we just don't have any interfaces for datagram > endpoints yet, since those are pretty esoteric and the only other use-case > besides UDP we can come up with is DTLS (which, due to session-management > issues, is also esoteric enough to require other setup). Right. -- --Guido van Rossum (python.org/~guido)
