> > If I had to do it over again, your suggestion would make sense; > > > > But having this in the os module, which deals with such low-level > > file descriptors, still strikes me as a pretty decent place to put > > it as well, and I don't think it's worth the bother of updating > > documentation and so on. > > I can think of another reason for making it a class > method: so that custom subclasses of file, or other > file-like objects, can override it to create objects > of the appropriate type. Yeah, this was the gist of Oren's post (if I understood it correctly). > But since it is an os-dependent feature, the implementation > of it probably does belong in the os module. > > So how about providing a file.fromfd() which calls > os.fdopen()? I've never seen anyone code a file subclass yet, let alone one that needed this. YAGNI? --Guido van Rossum (home page: http://www.python.org/~guido/)
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