2007/10/29, Greg Ewing <[EMAIL PROTECTED]>: > Guido van Rossum wrote: > > > That's because I don't find the synonyms a good idea. > > Even if it means that stream sockets then have the > same interface as all other stream-like objects in > the I/O system, so buffering layers can be used on > them, etc.? That seems like a rather good reason to > me. > > If you want to be pedantic about not having synonyms, > then fix send() and recv() so that they only work > on *non*-stream sockets, or have different classes > for stream and non-stream sockets. > > In other words, to my mind, for stream sockets it's > send and recv that are synonyms for read and write, > not the other way around. > > > On Windows you can't dup() a fd. > > Oh, blarg. Forget that part, then. > > But I still think it shouldn't be necessary to share > fds between different objects in the first place. > > This is the problem that would be solved by making > sockets have an interface that is directly usable by > higher layers of the I/O system. There would be no > need to reach down below the socket object and grab > its fd, so the socket would have complete ownership > of it, and it would get closed when the socket > object eventually went away. This would happen at > the C level, so cycles and __del__ methods wouldn't > be a serious problem.
Having the SocketIO wrapper works just as well. I agree we need some refactoring to deal with the ownership issue better, but having read() and write() methods on the _socket object is not the solution. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
