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