On Sat, Apr 14, 2012 at 5:06 PM, Christian Heimes <li...@cheimes.de> wrote: > Am 15.04.2012 00:56, schrieb Guido van Rossum: >> Well, if it's a real file, and you need a stream, that's efficient, >> and if you need the data, you can read it. But if it comes from a >> loader, and you need a stream, you'd have to wrap it in a StringIO >> instance. So having two APIs, one to get a stream, and one to get the >> data, allows the implementation to be more optimal -- it would be bad >> to wrap a StringIO instance around data only so you can read the data >> from the stream again... > > We need a third way to access a file. The two methods get_data() and > get_stream() aren't sufficient for libraries that need a read file that > lives on the file system. In order to have real files the loader (or > some other abstraction layer) needs to create a temporary directory for > the current process and clean it up when the process ends. The file is > saved to the temporary directory the first time it's accessed.
Hm... Can you give an example of a library that needs a real file? That sounds like a poorly designed API. Perhaps you're talking about APIs that take a filename instead of a stream? Maybe for those it would be best to start getting serious about a virtual filesystem... (Sorry, probably python-ideas stuff). > The get_file() feature has a neat benefit. Since it transparently > extracts files from the loader, users can ship binary extensions and > shared libraries (dlls) in a ZIP file and use them without too much hassle. Yeah, DLLs are about the only example I can think of where even a virtual filesystem doesn't help... -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com