Greg Ewing wrote:
Guido van Rossum wrote:
You can't blame KDE for providing mechanisms that only work in the KDE world. It's fine for Python to provide Python-specific solutions for issues that have no cross-platform native solution.
Also keep in mind that we're talking about resources used internally by the application. They don't *need* to be accessible outside the application. So I don't think the KDE argument applies here.
They might need to be available outside "Python". Two use cases:
1. The application embeds an sqlite database. Even though it knows how to get at the data, it can't use it, because the sqlite3 library won't accept .../foo-1.0.egg/resources/the_data (or some such) as a database name, if foo-1.0.egg is a ZIP file.
If the installed application was a set of files, that would work.
2. The application embeds an SGML DTD (say, HTML). In order to perform validation, it invokes nsgmls on the host system. It cannot pass the SGML catalog to nsgmls (using the -C option) since you can't refer to DTD files inside ZIP files inside an SGML catalog.
If this was a bunch of installed files, it would work.
3. The application includes an SSL certificate. It can't pass it to socket.ssl, since OpenSSL expects a host system file name, not a fragment of a zip file.
If this was installed as files, it would work.
This is precisely what happens in KDE: you have konqueror happily browse an SMB directory, double-click on a .xls file, OpenOffice starts and can't access the file it was started with. It doesn't matter to the user that there is "a good reason" for that.