Guide to the python interp. source?

Edward K. Ream edream at tds.net
Fri Jul 26 16:17:18 EDT 2002


I am writing this post on the theory that teaching something is the
best way to learn it myself.  If I have made any blunders I'm sure the
wizards will let me know gently :-)

Section 18, Python Language Services, of the Python Library Reference
contains information related to the interpreter and the compiler.
http://python.org/doc/current/lib/language.html

The primary documentation for opcodes appears to be in the documentation of
the dis (disassembler) module, section 18.10.1 of the Python Library
Reference: http://python.org/doc/current/lib/bytecodes.html

Although it seems very low level, I agree that looking at disassemblies is
actually very useful because you'll see what gets pushed and pulled from the
interpreter's stack by various constructs.  That in turn makes the
interpreter code much easier to figure out.

Python/ceval.c contains the interpreter proper. The cases for various
opcodes call two kinds of routines:  local (static) helper routines in
Python/ceval.c and routines of the C API. Therefore, an intimate knowledge
of just about everything in http://python.org/doc/current/api/api.html would
be good :-)

The quick way to get the documentation for the public routines is via the
P index page of the C API:
http://python.org/doc/current/api/genindex.html#letter-p
For example, PyDict_GetItemString is called early in one of the
interpreter's import cases. The documentation is accessible from the index
page, and clicking on the link takes us to Section 6.1, Object Protocol, of
the C API:
http://python.org/doc/current/api/object.html#l2h-165

However, "internal" C API routines (routines not meant to be used by the
general public) are not documented in the index.  For these, you must go to
the source.  The Include, Object, Modules and Python directories are the
first places to look for sources.  It's usually not too difficult to guess
where code is.

An earlier draft of this posting actually went step-by-step through the
interpreter code for the import cases.  I've eliminated it because it was
loooooong.  But that's where you might start:  just dive into the code and
figure out what every line does for some case you are interested in. Don't
take shortcuts: really understand every line of code--where it is defined,
where it is documented and what it really does.  As you get more experience,
you might be able to shortcut this step-by-step process, but at first I
recommend absolute thoroughness.  Anyway, that's what I am doing :-)

For the IMPORT_NAME case you'll end up at builtin___import__ in
Python/bltinmodule.c which in turn takes you to PyImport_ImportModuleEx in
Python/import.c.  The actual work is done in a helper routine called
import_module_ex.  I suspect that if you understand import_module_ex you
will understand everything there is to know about this kind of import.
Indeed, the leading comment for import_module_ex is
/* The Magnum Opus of dotted-name import :-) */

Edward
--------------------------------------------------------------------
Edward K. Ream   email:  edream at tds.net
Leo: Literate Editor with Outlines
Leo: http://personalpages.tds.net/~edream/front.html
--------------------------------------------------------------------









More information about the Python-list mailing list