Author ncoghlan
Recipients Arfrever, Marc.Abramowitz, Ronan.Lamy, brett.cannon, eric.snow, jcea, ncoghlan
Date 2012-11-18.10:50:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1353235836.14.0.865477247926.issue15031@psf.upfronthosting.co.za>
In-reply-to
Content
OK, rereading the whole issue and getting completely back up to speed with the problem we're trying to solve, I think parse_bytecode_container is a better name than any of my suggestions, since there is no cache involved for SourcelessLoader and similar cases.

I also think a static method is a bad idea, since that makes the preferred method of invocation unclear as the method is visible via a number of different loaders, and if you're just wanting to get the code object out of a bytecode file, it isn't clear why a loader is involved at all. So, I've gone back to Ronan's approach of a module level function.

The attached patch goes down that route - the public function *always* reraises the header errors, but in a way that SourceLoader.get_code can easily suppress. SourcelessLoader.get_code simply bypasses the public helper entirely (it *could* call it and unwrap the header exceptions for backwards compatibility, but that seems pointlessly convoluted).

The "fullname, data, bytecode_path" part of the API remains consistent across the 3 helpers, with optional source_* parameters at the end where appropriate.
History
Date User Action Args
2012-11-18 10:50:36ncoghlansetrecipients: + ncoghlan, brett.cannon, jcea, Arfrever, eric.snow, Marc.Abramowitz, Ronan.Lamy
2012-11-18 10:50:36ncoghlansetmessageid: <1353235836.14.0.865477247926.issue15031@psf.upfronthosting.co.za>
2012-11-18 10:50:36ncoghlanlinkissue15031 messages
2012-11-18 10:50:35ncoghlancreate