Brett Cannon added the comment:
It's a method so that it can be overridden. Otherwise I can't develop my
own format and have that be the only differing option from SourceLoader.
On Nov 18, 2012 7:50 AM, "Nick Coghlan" <rep...@bugs.python.org> wrote:
> Nick Coghlan added the comment:
> 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
> Added file:
> Python tracker <rep...@bugs.python.org>
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list