This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Ronan.Lamy
Recipients Ronan.Lamy, brett.cannon, ncoghlan
Date 2012-06-07.19:09:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2012-06-07 19:10:16Ronan.Lamysetrecipients: + Ronan.Lamy, brett.cannon, ncoghlan
2012-06-07 19:10:13Ronan.Lamysetmessageid: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za>
2012-06-07 19:10:12Ronan.Lamylinkissue15031 messages
2012-06-07 19:10:12Ronan.Lamycreate