Message175862
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. |
|
Date |
User |
Action |
Args |
2012-11-18 10:50:36 | ncoghlan | set | recipients:
+ ncoghlan, brett.cannon, jcea, Arfrever, eric.snow, Marc.Abramowitz, Ronan.Lamy |
2012-11-18 10:50:36 | ncoghlan | set | messageid: <1353235836.14.0.865477247926.issue15031@psf.upfronthosting.co.za> |
2012-11-18 10:50:36 | ncoghlan | link | issue15031 messages |
2012-11-18 10:50:35 | ncoghlan | create | |
|