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" <report@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
> appropriate.
>
> ----------
> Added file:
> http://bugs.python.org/file28022/issue15031_parse_container_function.diff
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue15031>
> _______________________________________
>