Guide to the python interp. source?

Andreas Kostyrka andreas at kostyrka.priv.at
Sun Jul 28 10:45:29 EDT 2002


Am Sam, 2002-07-27 um 21.15 schrieb Tim Gahnström /Bladerman:
> This is not the comon way, I know that but I am inclined to say that it is
> "undoubtley" more intuitive. Remember that this is a language for complete
> beginners with no programming experience.
Well, and how does it work with recursion? Just wondering. ;)
[And recursion is such a fundamental pattern in programming, that you
want your students to understand it quickly. Actually it's also needed
for the maths.]

> Ofcourse this is just the simplest case possible and ther vill be issues
> further down the way but I intend to handle them later. right now I am
> getting to no the python interpreter, and its interaction with C and the IDE
> Maybe I have gotten the names wrong imutable/mutable/CBR/CBV etc etc. But my
> intentions are as outlined above.
Well, I've got the strong impression, that you have not yet the feeling
for the Python datamodel. While it can probably somehow done, you are in
myriad of troubles. (And I suspect that you will not be able to work it
out in a semester. Perhaps even two semesters ;) )

The fundamental facts about mutable/immutable objects are at the core of
Python. So is the datamodel without "variables", just name bindings. (In
some way, the fundamental data structure of Python is a dictionary, as
was a cons-cell for Lisp.)

Because dictionaries are so fundamental, the mutable/imutable separation
is fundamental too. (It takes much creativity to make mutable keys even
partly work.)

And consider the fact, that you would have to completely rewrite the
python library also, because basically every piece of python code relies
upon call by value.


> After I had written this mail actually thought that I had to add this on
> top:
> CBR is not a die hard feature that I must have if it gets a whole lot of
> work to fix it. But I would apreciate anny suggestions on how to make it
> with a limited amount of work.
Forget it :)
Write some small (~1000KLOC) applications in Python, do some data
manipulation stuff, and then reconsider your project ;)

Actually one funny side note on CBR:

Calling
a.method()
would allow the method to change the object that a is pointing to,
because the method gets an explicit self parameter that points to a, ...

> That I understand but hadn't thought about it. What might be possible now
> when you point it out like that is that maybe I can use the current Python
> model untill I come to a return statement in a function. At that time I
> reattatch the internal object to the pointer/refference/name that I sent in.
> Clearly neither this is well thought over. I will come there in a month or
> so.
Well, it's usually a bad idea to try fixing a language, that you do not
know well enough. Especially if you don't know the basic "idioms".

And I strongly question the fact if passing values by reference is
easier to understand than assigning values. (which call by value is)

> >ones do such intrusions in their callers' namespaces.
> From my point of view such intrusions is not a bad thing, this language is
> for beginners and not for critical aplications.
> If that is most intuitive and don't come with alot of problems it is also
> the best.
But this kind of changes is not intuitive. The only people that will
find this intuitive are FORTRAN and perhaps BASIC diehards ;)

> From: "Terry Reedy" <tjreedy at udel.edu>
> > In a real sense, Python does not have variables.  It has objects, each
> > of which has 1 or more named or unnamed references thereunto.
> 
> Okey this is what I have to work with then and from that modify the
> interpreter so the novice get the feeling that it works as I outlined above.
> Maybe I am working against the python modell I dont know that yet but I am
> confident I will know when the time comes.
> If that is the case I will either have to rethink my priorities or change
> Language to work with (change of language ofcourse get less likely the more
> time gets by and the more code I write).
> I might even throw in a preprocessor that changes the usercode into python
> right before it is ran. That ofcourse is not a good solution but I have t in
> mind.
Nope. Preprocessor would be a quite bad idea. Makes for bad error
messages, and python is dynamic enough, that some running code could
discover that it was mangled and go in some creative way wrong.

Andreas





More information about the Python-list mailing list