>> 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. Yes. Which has always struck me as slightly ugly. >> 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. I guess you would keep the send() and recv() interfaces for raw access, and add read(), write(), readlines(), etc, which would be buffered. I'd chose to then view it as a superset of a file-like object. >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. And get rid of stdio along the way, with any luck... 8-) It would also be nice to make the buffering play nicely with select()/poll()-threaded applications... if we're talking about wishlists... 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4