Re: [Python-Dev] __file__
Nick Coghlan wrote:
Another option is to remove bytecode-only support from the default filesystem importer, but keep it for zipimport (since the stat call savings don't apply in the latter case).
+1 Baptiste Carvello wrote:
However, making a difference between zipimport and the filesystem importer means the application will stop working if I unzip the library zip file, which is surprising. Unzipping the zip file can be handy when debugging a bug caused by a forgotten module.
If the ZIP contains only bytecode files, it is just not intended for changing any code, so I don't think this is an argument. If you have access to the source code, you still can use that instead of messing around with byte code. Henning
Henning von Bargen wrote:
If the ZIP contains only bytecode files, it is just not intended for changing any code, so I don't think this is an argument. If you have access to the source code, you still can use that instead of messing around with byte code.
That doesn't apply when it is the app developer trying to figure out why their app is breaking when they throw it in a bytecode only zip :) It's a moot point anyway - Guido has pronounced that the bytecode-only support will be left alone by PEP 3147 even if the other caching changes are eventually accepted. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Mar 04, 2010, at 11:25 PM, Nick Coghlan wrote:
It's a moot point anyway - Guido has pronounced that the bytecode-only support will be left alone by PEP 3147 even if the other caching changes are eventually accepted.
Right. I should have stopped while I was ahead. We'll just keep what's in the PEP. -Barry
participants (3)
-
Barry Warsaw -
Henning von Bargen -
Nick Coghlan