[Python-Dev] __file__ and bytecode-only

Nick Coghlan ncoghlan at gmail.com
Tue Mar 16 10:44:27 CET 2010

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).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list