New submission from Ronan Lamy <ronan.l...@gmail.com>:

I think it would be beneficial to extract the handling of the binary format of 
bytecode files from the rest of the loader/finder code in importlib._bootstrap. 
That means exposing, internally at least, functions that do nothing more than 
convert the binary contents of a .pyc file to/from metadata + code object. They 
would help in testing and implementing alternate loaders and would prevent the 
kind of code duplication that led to issue 15030.

I'm adding a patch implementing extracting a _loads_pyc() function from 
_bytes_to_bytecode(). Note that:

* _loads_pyc() has only one parameter, instead of 5 for _bytes_from_bytecode.
* The raising of exceptions is more consistent: _loads_pyc being an IO helper, 
it never raises ImportError. Thanks to exception chaining, no information is 
lost, though.

Obviously, this should be complemented with a _dumps_pyc(). Then there's the 
question of whether these functions should be public and what the best 
interface is - I actually feel that the natural home of both functions is in a 
lower level module, either imp or marshal.

So, should I get on with it, or are there things I overlooked that make this a 
bad idea?

----------
components: Interpreter Core
files: loads_pyc.diff
keywords: patch
messages: 162489
nosy: Ronan.Lamy, brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: Split .pyc parsing from module loading
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25860/loads_pyc.diff

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15031>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to