Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <4e3bffe1$0$29996$c3e8da3$5496439d@news.astraweb.com>
References: <mailman.1917.1312528828.1164.python-list@python.org> <4e3bffe1$0$29996$c3e8da3$5496439d@news.astraweb.com>
Date: Fri, 5 Aug 2011 10:46:02 -0600
Subject: Re: Observations on the three pillars of Python execution
From: Eric Snow <ericsnowcurrently@gmail.com>
To: "Steven D'Aprano" <steve+comp.lang.python@pearwood.info>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1931.1312562764.1164.python-list@python.org>
Lines: 114
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:10913

On Fri, Aug 5, 2011 at 8:36 AM, Steven D'Aprano
<steve+comp.lang.python@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.  For classes and modules
the code object is executed and then discarded.  I covered this
explicitly in one of the observations.

>
> The simplest possible module just has a name:
>
>>>> import sys
>>>> module =3D type(sys)
>>>> module("name")
> <module 'name' (built-in)>
>
> Or if you prefer to do it the "normal" way by importing from source code,
> the simplest source code of all is just an empty file.
>
> A module is an object with a __dict__, a __name__, and a __docstring__ wh=
ich
> defaults to None. That's it. No code objects, unless you populate the
> __dict__ with functions, but it is the *functions* that have the code
> objects, not the module itself. The module is just a container.
>
> Classes are similar. The simplest class:
>
> class K:
> =A0 =A0pass
>
> or if you prefer:
>
>>>> type('K', (), {})
> <class '__main__.K'>
>
>
> Again, no code objects unless you populate the dict with functions (which
> get turned into methods). Again, the class object is just a container. A
> more complex container than modules, with a richer set of inherited
> behaviour, but still just a container.
>
> The signature for creating a function is very different:
>
> help(type(lambda: None)) =3D>
>
> class function(object)
> =A0| =A0function(code, globals[, name[, argdefs[, closure]]])
> =A0|
> =A0| =A0Create a function object from a code object and a dictionary.
> =A0| =A0The optional name string overrides the name from the code object.
> =A0| =A0The optional argdefs tuple specifies the default argument values.
> =A0| =A0The optional closure tuple supplies the bindings for free variabl=
es.
>
>
> The simplest function I can think of:
>
>>>> co =3D compile('pass', '', 'single')
>>>> f =3D type(lambda: None)(co, {})
>
> Even simpler than
>
> def f():
> =A0 =A0pass
>
> Can you see why?
>
> If you inspect a function object, you will see that it always has a code
> object, even if the code object does nothing but return None:
>
>>>> import dis
>>>> dis.dis(f.func_code)
> =A01 =A0 =A0 =A0 =A0 =A0 0 LOAD_CONST =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 (None=
)
> =A0 =A0 =A0 =A0 =A0 =A0 =A03 RETURN_VALUE
>
>
> There may be some other obscure built-in type that includes code objects,
> but I can't imagine what it would be. I feel confident in saying that
> functions, and functions alone, contain code. Even methods are just
> wrappers around functions. Even built-in functions like len don't contain
> code! (Or at least, their code isn't accessible from Python.) Which makes
> sense, if you think about it: their code is part of the Python virtual
> machine, not the object.

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.

I've always found your frequent responses very insightful and
thoughtful, Steven, and I appreciate that.  In this case I can only
imagine that my opening statement was unclear enough that you did not
continue to read the rest, where the context of my point was more
clear (I hope :).  Regardless, thanks for taking a look.

-eric

>
>
> --
> Steven
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>