Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10891

Observations on the three pillars of Python execution

Show all headers | View raw

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.  Each has its own role to play and
the differences between them mostly reflect that.  Here are some
observations (based on default behavior):


Object creation relative to code object creation:
(M) before
(C) after
(F) after

Object creation relative to code object execution:
(M) before
(C) after
(F) before

Object available during code object execution:
(M) no
(C) no
(F) no

Code object destiny:
(M) executed once at definition time, then discarded
(C) executed once at definition time, then discarded
(F) not executed at definition time, stored on the function
     object for execution with each __call__() invocation.

Execution locals is available during code object execution:
(M) as globals()
(C) as locals()
(F) as locals()

Object namespace is execution locals of code object:
(M) yes
(C) more or less
(F) completely distinct

Unique syntax:
(M) 'import' statement
(C) 'class' statement
(F) 'def' statement

Mechanism triggered by respective syntax:
(M) import machinery (import.c/importlib)
(C) internal, but partially exposed via metaclasses and the
     __build_class__ builtin
(F) internal, nothing exposed

Override capability:
(M) complete capability through builtin __import__ and PEP
      302 import hooks
(C) partial capability, before code object execution through
     metaclass __prepare__() and after through __build_class__()
     and metaclass __call__(), __new__(), and __init__()
(F) no capability

Post instantiation modification capability:
(M) yes
(C) yes
(F) mostly (some attributes are read-only)

Mechanism to instantiate outside of respective unique syntax:
(M) imp.new_module(), types.ModuleType(), type(<module>)()
(C) type()
(F) types.FunctionType(), type(f)()

Type extensibility:
(M) Not relative to 'import' syntax (by default)
(C) Complete
(F) No

Name available during definition execution:
(M) as __name__
(C) only through metaclass __prepare__()
(F) through inspect.currentframe().f_code.co_name

Name available on object as __name__:
(M) yes
(C) yes
(F) yes


Corrections, additions, and comment are welcome.

-eric

Back to comp.lang.python | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Observations on the three pillars of Python execution Eric Snow <ericsnowcurrently@gmail.com> - 2011-08-05 01:20 -0600
  Re: Observations on the three pillars of Python execution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-06 00:36 +1000
    Re: Observations on the three pillars of Python execution Eric Snow <ericsnowcurrently@gmail.com> - 2011-08-05 10:46 -0600
      Re: Observations on the three pillars of Python execution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-06 03:29 +1000
        Re: Observations on the three pillars of Python execution Eric Snow <ericsnowcurrently@gmail.com> - 2011-08-05 16:21 -0600
          Re: Observations on the three pillars of Python execution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-06 12:05 +1000
    Re: Observations on the three pillars of Python execution Mel <mwilson@the-wire.com> - 2011-08-05 14:22 -0400
      Re: Observations on the three pillars of Python execution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-06 12:01 +1000

csiph-web