I wrote: > Seems to me that a socket should already *be* a file, > so it shouldn't need a makefile() method and you > shouldn't have to mess around with filenos.
Guido van Rossum wrote: > That model fits TCP/IP streams just fine, but doesn't work so well for > UDP and other odd socket types. No, but I think that a socket should have read() and write() methods that work if it happens to be a socket of an appropriate kind. Unix lets you use read and write as synonyms for send and recv on stream sockets, and it's surprising that Python doesn't do the same. At the very least, it should be possible to wrap any of the higher-level I/O stack objects around a stream socket directly. > The real issue seems to be file descriptor GC. Maybe we haven't > written down the rules clearly enough for when the fd is supposed to > be GC'ed I don't see what's so difficult about this. Each file descriptor should be owned by exactly one object. If two objects need to share a fd, then you dup() it so that each one has its own fd. When the object is close()d or GCed, it closes its fd. However, I don't see that it should be necessary for objects to share fds in the first place. Buffering layers should wrap directly around the the object being buffered, whether a file or socket or something else. Then whether the socket has a fd or not is an implementation detail of the socket object, so there's no problem on Windows. Bill Janssen wrote: > Back to your initial mail (which is > more relevant than Greg Ewing's snipe!): What snipe? I'm trying to make a constructive suggestion. > then in some > cases *closes* the socket (thereby reasonably rendering the socket > *dead*), *then* returns the "file" to the caller as part of the > response. I don't understand that. What good can returning a *closed* file object possibly do anyone? -- Greg _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
