On 1 July 2014 01:27, Andrew Barnert email@example.com wrote:
(Replies to both Guido's top-post and Nick's reply-post below.)
On Monday, June 30, 2014 7:19 PM, Guido van Rossum firstname.lastname@example.org wrote:
Like bytecode, the compiler's workings are not part of the language spec, and are likely to change incompatibly between versions and not work for anything besides CPython. I don't really want to go there (cool though it sounds for wannabe compiler hackers).
But CPython does expose bytecode via the dis module, parts of inspect, etc. For that matter, it exposes some of the compiler's workings (especially if you consider everything up to AST generation part of the compiler, since every step up to there is exposed, including doing the whole thing in one whack with PyCF_ONLY_AST). So, I don't see how exposing the AST-to-bytecode transformation part (or, while we're at it, the .pyc generation part) is any more unportable than what's already there.
Note that the dis module has a "CPython implementation detail" disclaimer, and the AST structure is deliberately exempted from the usual backwards compatibility guarantees.
As far as hooking compilation goes, https://docs.python.org/3/library/importlib.html#importlib.abc.InspectLoader... was added in 3.4 specifically to make it easier to define custom loaders that make use of most of the existing import machinery (including bytecode cache files), but do something different for the source -> bytecode transformation step.