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 lifes 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. 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. Christian _______________________________________________ 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
