
Line oriented network protocols are very common, and I often find myself calling the socket makefile method so I can read complete lines from a socket. I'm probably not the first one who's wished that socket objects where more file-like.
While I don't think we'd want to go as far as to turn them into a stdio based file object, it might make sense to allow them to be iterated over (and add a .readline() method, I guess). This would necessitate adding some input buffering, which will complicate things like the .recv() method, so I'm not sure it's that good an idea, but it removes one gotchya for neophytes (and forgetful veterans). Thoughts?
Um, why doesn't the makefile() method do what you want?
The short answer is that it does, but not very tidily - by turning the socket object into a file object, I lose the original socket object functionality (for example, shutdown()). At another level, the concept of a "file-like" object is a very common python idiom - socket is the odd one out these days. It's really not a big deal - we could regularise the interface at the cost of more implementation complexity. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

Line oriented network protocols are very common, and I often find myself calling the socket makefile method so I can read complete lines from a socket. I'm probably not the first one who's wished that socket objects where more file-like.
While I don't think we'd want to go as far as to turn them into a stdio based file object, it might make sense to allow them to be iterated over (and add a .readline() method, I guess). This would necessitate adding some input buffering, which will complicate things like the .recv() method, so I'm not sure it's that good an idea, but it removes one gotchya for neophytes (and forgetful veterans). Thoughts?
Um, why doesn't the makefile() method do what you want?
The short answer is that it does, but not very tidily - by turning the socket object into a file object, I lose the original socket object functionality (for example, shutdown()).
You can just keep the socket around though.
At another level, the concept of a "file-like" object is a very common python idiom - socket is the odd one out these days.
It's really not a big deal - we could regularise the interface at the cost of more implementation complexity.
I'm not sure if I'd call that regularizing. It would by necessity become some kind of odd mixture. In any case, I find the file abstraction a bit arcane too. Maybe we should strive to replace all these with something better in Python 3.0, to be prototyped in the standard library starting with 2.4. --Guido van Rossum (home page: http://www.python.org/~guido/)

>> Um, why doesn't the makefile() method do what you want? Andrew> The short answer is that it does, but not very tidily - by Andrew> turning the socket object into a file object, I lose the Andrew> original socket object functionality (for example, shutdown()). Would it be sufficient for the close() method on the object returned by sock.makefile() to call shutdown(2) on the underlying socket? Skip

Skip Montanaro <skip@pobox.com>:
Would it be sufficient for the close() method on the object returned by sock.makefile() to call shutdown(2) on the underlying socket?
I don't think that would be very useful - shutdown() is normally used to shut the socket down in one direction only. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
participants (4)
-
Andrew McNamara
-
Greg Ewing
-
Guido van Rossum
-
Skip Montanaro