Guide to the python interp. source?

Tim Gahnström /Bladerman tim at bladerman.com
Sat Jul 27 09:19:45 EDT 2002


"Alex Martelli" <aleax at aleax.it>
> Tim Gahnström /Bladerman wrote:
> > Is there a guide or a recomended way to "get to know" the source code to
> > the python interpreter?
>
> Assuming you're familiar with Python's C API (the online docs are good,

I guess maybe I must start out there and write some C/python modules to get
a feel of that before I start pooking around in the interpreter

> and interpretation of bytecode.  Those are nasty, particularly (as
Thanks, that really encouraged me :-)

I will have a look at the places you mentioned that I sniped out to.

> of 2.2.1) the compilation.  Then you can look at other more
> marginal nasties such as garbage collection &c.

That is probably not an isue I must look into much at all

> > and I will need to monitor the state of the interperter for debugging
> > purposes
>
> Instrumenting the interpreter to understand what exactly is
> going on is not hard and does not require complete understanding,
> indeed doing and examining such instrumentation will HELP you
> further your understanding.

I hope so, I actually am starting to think that I will learn a whole lot
during this project, not just about Python and the Python interpreter but
about CS in general and looking at other peoples code in particular.

> Modification is of course another kettle of fish:-).
To bad, my plan is actually to have al variables that ar curently in use in
a debuggerpanel on one of the sides al the time and also have an inputbox
there for the user to be able to change any variable at will.

> > Python is, I think, a verry intuitive language for beginners, with some
> > modifications it can be even better. Especially with a good IDE. That is
>
> Two mostly separate issues, I think -- the really good IDE is pretty
> uncontroversial (if really good:-), the mods WILL get you flames:-).
Definitley separate issues but I felt that both neede a rewrite to make a
really good novice suite.
It seems like a few people are interested in the project so I will post more
on the changes I intend to make and why when I have come a little furter. I
assume I will see some flaming but remember the good thing with doing a
project of your own. You can end discussions whenever you want and you dont
have to care about either flames nor advices :-)

> > one of those people that can have a look at a million lines of code and
se
>
> It's nowhere like a million lines!  264k overall including ALL the
> platform-dependent goo you don't AT ALL care about.  Given that
> Modules and Objects are separable, modular and clear, the hard
> core is just 30k lines or so in Python/*.c and Parser/*.c.

Well, I dindn't actually think it would be a milion lines :-), I just meant
that there is to much to be overlookable.

> > Things I want to change is for example, everything should be "call by
> > refferense", it shall not by case sensitive, redirect output, better
> > errormesages, etc, etc.
>
> Better error messages would of course be a welcome contribution
> to Python itself:-).

Yes, I actullay think the current once are quite bad, I hope my project is
aplicable on the reall interpreter so they can be incorporated in the futre.

> "redirect output" is a mystery -- Python's
Argh as I said in a reply to Hudson, it was written in a haste and didn't
mean much. I have also written a samll errormessage example there.

> insensitivity is what gets my personal applause: it's the ONE
> feature of the language I truly, deeply dislike (just as I
> dislike it in Unix, XML, C, ...).  You're in for substantial
> work with the *libraries*, I think (not the C-coded ones --
> the Python-coded ones).

Maybe, maybe not,
Maybe I can just convert everything internaly to uppercase? I don't know,
havn't given it much thought yet.

> "Call by reference" I gotta see.  Just for fun, do it like
> good old Fortran used to:
>
> def inc(x):
>     x = x + 1
>
> inc(2)
> print 2
>
> should of course print '3'.

I have thought about that and that is not what I want. In this particular
case I want an integer object to be created with the value 2, that is sent
to inc and changed but when we come to the next line that object will be
garbage collected because none have a refference to it.
Inc will work as it is supposed to do wich is good if you just want to have
the sidefects of it. An other possibility would be to generate a good
looking errormessage. Because it is likely a mistake.

> I suggest you consider "value/copy-return" as an alternative:
I will absolutely consider it.

> The hard part comes in determining what you want to
> happen on e.g.:
>         f(x, x.y, x.y.z, x.y.z.t)

Cheesch! I will consider that by christmas :-)

Thanks alot!

Tim





More information about the Python-list mailing list