Guide to the python interp. source?

Tim Gahnström /Bladerman tim at bladerman.com
Sat Jul 27 15:15:00 EDT 2002


Hi
Here comes my reply to both Alex Martelli and Terry Reed.
First I want to point out that I didn't start this discussion with the
intention of discussing features of the language. I have about four months
left of the time I intend to spend on the project so everything is not
completely worked out yet. The features we are discussing now are just
things that I took out of my head in a snap to make examples.

Another issue is that I am not a Python master hacker, I have used maybe ten
languages over the last couple of years and have only recently picked up
Python (and love it ofcourse :-)). I do on the other hand belive I will be
quite fluid in Python by christmas.

Regarding this CBR mess.
The asignment will be a special case, it will be call by value.
a=2
b=a
b=3
will leave the program in a state where a=2 and b=3
a and b can never point at the same place or at the same object.

when it comes to calling functions it will look like this

def setTo3(x):
    x=3

a=2
setTo3(a)

this will leave the program with a being 3
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.

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.

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.

Alex martelli wrote
>Don't confuse *mutating an object* with *reattaching a name to a
>different object*.  Completely different issues.

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.

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


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.

> do *you* think of as variables:  objects, references, or names?

Actually I couldnt care less, I am happy when I get to know how it is done
in Python right now. I will change my mind to whatever is corret for this
particular project. In the discussion so far I think I have had objects with
one refference to them in mind so far.


> x = 2
> ...
> y = x
> ... (many lines)
> x = x*x
> # what should now be the value of y?  2 or 4?
> # immutability of ints guarantees 2, which is what most people expect

It certainly is not what a novice expects. And therby not what will happen
in this language.
The line
> y = x

will only cause y to have a copy of the value that x had at the moment.

> > When you want to make functions like inc(x) where inc is supposed to
> > increase the value of x by one. How is that done in Python?
>
> You 'mutate' names most easily by rebinding them to a new value with
> the binding (assignment) operator '=' as in 'x = x+1', 'x+=1', or even
> x=inc(x)'.  With work, you could make inc('x') work for global var x
> by fiddling with the globals dict (but this cannot be done for local
> function vars).  Note that in C, you would also have to 'quote' x,
> though with the '&' operator, as in inc(&x).

That is the way I have to do it in C it works like a charm when you know it
but it is not easy to figure out when you havn't programmed before. I don't
argue with you here just... rambling actually :-)
But what you say about x += 1 is interesting. the easy way to create such a
thing (for the interpreter creator) would be to make a function called +=,
make it infx and make it look like this.

def +=(value, adder): infx'
    value=value+adder

but that ofcourse is not the way it is done since that is not supported in
Python. Instead it must be aspecial case of assignment and handled as an
asignment by the interpreter instead of "yet another function" This I assume
would make the interpreter bigger wich might not be a good thing.
Again I am not arguing I am just facing facts and trying to see
possibilities for me to solve my problem. Maybe I could make my assignments
yet another special case (dont think so but maybe).


> If you work with instead of fighting the Python data model, you can
> probably do what you want without completely reworking the
> interpreter.

I will do my best to not fight Python. I am just one person and have a
limitet time to finish this so I will not rework the interpreter. Up untill
now I have designed the language the novice in the first room and hoe
pythonm works in the second. BUt I guess I will have to change a few things
to reduce the workload.
Maybe this is one of the issues I must rethink.

>From Alex Martelli
>With your language, you will have to teach separately
>two different semantics, one for assignment and a subtly
>different ones for argument passing, making it harder for
>beginners that a language where just one semantics exists.

That is correct. I have to teach them that there is a diffreence betwen
asignment and variable passing.
The problem is that I think that is verry easy to understand and you dont. I
call it a difference of opinoins not right or wrong.
There will be two things to explain in both cases.
I must explain that by assigning a a to b means that a gets a copy of the
value in b
You must explain that in a function when you try to asing a value to one of
the parameters it won't effect the outside or that it is illegal.


Tim Gahnström





More information about the Python-list mailing list