Guide to the python interp. source?

[Tim Gahnström /Bladerman]

"Edward K. Ream" <edream at tds.net>
> I am writing this post on the theory that teaching something is the
> best way to learn it myself.

Any reason for helping me out is a good reason :-)

>  If I have made any blunders I'm sure the wizards will let me know gently
:-)

Well... Don't look at me, I wouldnt smell a blunder if you pushed them down
my throat :-)

> 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
> Reference: http://python.org/doc/current/lib/bytecodes.html

I had missed both those completley, thanks for pointing them out.

> 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.

It won't be fun, but I keep telling myself that I do this for education :-)

> 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.

It is quite understandable that none have bothered to make a particulary big
documentation to the internals that is not even intendet to be looked at by
more then a handfull of people.
Thanks alot for all the links, python.org seems to be down now but I will
look in there a little later.

> 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 :-)

but that is sooo tiresome!... It takes alot of time and it gets frustrating
:-)
But I guess I will end up doing that in time. Now atleast I have alot of
pointers to good startingplaces.

Thanks for taking time to answer me!

Tim