Observations on the three pillars of Python execution
ericsnowcurrently at gmail.com
Sat Aug 6 00:21:47 CEST 2011
On Fri, Aug 5, 2011 at 11:29 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Eric Snow wrote:
>> On Fri, Aug 5, 2011 at 8:36 AM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Eric Snow wrote:
>>>> In Python, three types of objects have special syntax and mechanics
>>>> for their instantiation, during which a code object is generated:
>>>> modules, classes, and functions.
>>> I believe you are labouring under a misapprehension. Modules and classes
>>> don't generate code objects.
>> Sorry for any confusion. I was talking specifically about the their
>> instantiation through their respective special syntax. During that
>> process a code object is generated for each.
> Do you believe that this process of generating a code object and throwing it
> away is a part of the Python language specification, which any compiler
> must do in order to call itself "Python", or a mere implementation detail?
That's a great point which I hadn't considered. Honestly, I only used
my experience with CPython in making these observations. After
reviewing the language reference I see that I missed out on a bunch of
nomenclature that would have made things more clear, and I got a few
points wrong, which you pointed out. :)
Regarding code objects and classes, your are right. The language
reference indicates the following:
"The class’s suite is then executed in a new execution frame...When
the class’s suite finishes execution, its execution frame is discarded
but its local namespace is saved." 
So the use of code objects for execution is an implementation detail.
Instead of "code object" I should have referred to the code executed
in the execution frame or just to the frame. Incidently, I had not
realized that the builtin __build_class__() is also an implementation
For modules, the language reference doesn't say anything about how
execution is accomplished, which only matters when execution is
involved in the creation of the module object. It does refer to
importlib as a reference implementation. The order-of-operations
observations I made are based on that reference implementation.
> Is this documented somewhere? If it is not documented, what makes you think
> that it happens at all? You are writing as if it were self-evidently true,
> but I don't believe it is self-evident at all. I think you need to
> demonstrate the truth of two of those three pillars, not just take them for
>> For classes and modules
>> the code object is executed and then discarded. I covered this
>> explicitly in one of the observations.
> I think your definition of "explicitly" and mine differ here.
>> Agreed that [non-builtin] functions are the only objects that have a
>> code object attribute. However, they are not the only objects for
>> which a code object is generated and executed.
> Are you talking about the fact that importing a module, class statements and
> function statements all involve executing a block of code?
> How does that differ from executing any other fragment of code?
The difference is that modules, classes, and functions (really the
function body) are code blocks tied to syntax that results in module,
type, and function objects. There are other code blocks but none of
them have a unique syntax, much less one that results in an object of
the corresponding type. This is relevant for trying to find the
object that corresponds to an execution frame, which is what led me to
my original post and drove the direction of the observations I made.
Anyway, I appreciate the feedback! I'm going to have to revisit my
observations with the language definition in hand. You've been really
insightful, as usual.
> Modules are special, of course, because they can get compiled to byte-code,
> but I trust you're not talking about .pyc files.
More information about the Python-list