[Python-Dev] file and bytecode-only (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Mar 16 10:44:27 CET 2010
- Previous message: [Python-Dev] __file__ and bytecode-only
- Next message: [Python-Dev] __file__ and bytecode-only
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Barry Warsaw wrote:
On Mar 14, 2010, at 12:17 AM, Nick Coghlan wrote:
While it's probably OK if the import side-effects only create files using the new scheme, the standard library modules will likely need to support both schemes (although I'm not sure if "same as import system" or "same as Python 3.1" make more sense as the default semantics - probably the former). I don't understand this point. compileall probably /could/ be extended to understand bytecode-only (i.e. legacy or <3.2) layout. I've added that to the PEP too.
In Python 3.1, invoking py_compile.compile() will create 2.x style bytecode. Similarly, when force==False, compileall.compile_dir() and compileall.compile_path() will check for 2.x style bytecode in order to decide whether or not to compile the module.
The question for 3.2 is what bytecode layout py_compile.compile() should generate. For the precompile-a-system-library use case it should clearly generate a PEP 3147 layout and this probably makes sense as the default behaviour in 3.2.
However, for production of bytecode-only packages, it would be convenient to be able to explicitly invoke the 2.x style behaviour without having to specify the target filename explicitly using the 'cfile' parameter (which isn't exposed at the compileall layer anyway).
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] __file__ and bytecode-only
- Next message: [Python-Dev] __file__ and bytecode-only
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]