Guide to the python interp. source?

"Michael Hudson" <mwh at python.net> skrev i meddelandet

but I would also be happy if I found a small description och what
code is where,

Well, the interpreter mainloop is in Python/ceval.c, object type
implementations are in Object/*.c, ...

<...>

Reading Include/object.h (and maybe other headers -- objimpl.h?) might
give some clues.

That is a start atleast, thanks for that, I will start my explorations there

or anything like that. A lot of projects have "a small guide for
wannabe developers" but I havn't found anything like that for this

There's http://www.python.org/dev/, but there's nothing of the sort
you're asking for here, really.

I noticed, but thought that I just had missed it. I thought there must be
some where for such a large project. But the problem is ofcourse ever
present, "nobody likes to do documentation"

Things I want to change is for example, everything should be "call by
refferense",

x += 1
i = 2
f(i)
i --> 3
then you have problems.

That is exactly what I want to have, that is more intuitive I think and I
don't think it must be that hard either. It is not a speed issue so it must
not be a true CBR. I will probably figure out some ugly hack to make it seem
like CBR.
Maybe look into value/copy return as Alex Martelli mentioned. What I want is
not really CBR but the, from Ada known "in out parameters" or the Pascall
"var parameter".

redirect output,

Probably easy. Not quite sure what you mean here.

Didn't really mean anything briliant there, it was just small things that
poped out of my head while I was writing.
I meant I want all output (text, graphics, buttons, etc) in a certain window
in the IDE I am creating.

better errormesages,

Examples? Feel free to contribute these back to the project...

Ofcourse I will contribut them back if I create something there that is
usefull for alot of people.
Maybe the error messages I want to have is not so badly needed for
experienced programmers but more for beginners.
A traceback is for instance really cryptic to a novice programmer I want an
errormessage to look loike this.

"The program stopped running for some unknown reason. It is likely an error
on line 23 in the file "myprog.cod":
if (max(3)>variable):
The error is probably caused by the call to the function max(). If you mean
to call the built in function max it must have two arguments, namely "val1"
and "val2" but you only supply it with one argument (constant 3).
On the other hand it might also be a misspelled call to your own function
maz() in "mylib.cod"
"

Currently the errormessage looks like this instead:

"Traceback (most recent call last):
File "<pyshell#8>", line 1, in ?
if max(3)>variable:
TypeError: min() or max() arg must be a sequence"

It is ofcourse likely that I won't be able to create an errormessage just
like I want but atleast that is my future goal.

Thanks alot for the time you took to answer.

Tim

Huaiyu Zhu

2002-07-29 18:32:37 UTC

"Terry Reedy" <tjreedy at udel.edu>

Things I want to change is for example, everything should be "call
refferense",

It already is, which is why functions can mutate mutable objects.
(This surprises some beginners.) Of course, for immutables (numbers,
strings, tuples), there is no semantic difference between reference
and value passing except for reduced memory usage.

I want to make all variables mutable. 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?
That is my view of CBR, maybe that is not the correct definition and I don't
need CBR.

It's not a matter of how you can do it, but what you really want to do.
Consider this:

x = y = 3 # (1)
inc(x) # (2)
x == 3 and y == 3 # (3)
x == 4 and y == 3 # (4)
x == 4 and y == 4 # (5)

Let's see what constraints you have for the semantics of inc.

- After (1), both x and y are references to an object named 3.

- Whatever you want your new language to be, you do not want the object
named 3 to actually have a value of 4. So you do not want to change the
object referenced by x.

- You can change the name x so that it now points to the object named 4.
You can keep the change in the function inc, so that (3) is true (as
Python currently does), or let it affect the calling scope, so that (4) is
true (as you might want to do). Either way (5) is false because y is a
separate name.

- To make (5) true, there must be a commont "sign post" to which both x and
y can refer to, and which can be changed from pointing to the object named
3 to the object named 4. This would be just a mutable int. It can be
implemented in existing Python similar to UserDict and UserList. You
would need change (1) to x = y = UserInt(3) to use it. Keep in mind that
you do not want the object named 3 itself to be mutable. Otherwise you
are in for a big surprise next time you do z = 3.

I guess what you want is (4), ie to make inc(x) change the reference of x in
the calling scope. In other words, you want to make the formal arguments of
a function an alias of the actual arguments. In that case these arguments
are really in a "tunneled" scope, accessible from both sides of a function
call. It would behave very differently from existing Python. For example:

def remove(x): del x
s = 3
remove(s)
s # NameError: name 's' is not defined

It might even be more powerful than Python in the sense that many statements
and syntax structures can be replaced by functions. Since functions are
first class objects you can manipulate them in program, thereby construct
program structures without using eval. This has a Lisp feeling. If you
decide that this is indeed what you want to do, other people might give you
some idea on how easy/difficult it is and where to start.

Huaiyu

Andreas Kostyrka

2002-07-28 14:45:19 UTC

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

Probably not. You should try first to see how many collisions you get by
going case insensitive.

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.

Nope it is not.
Or you forbid also constructs like:
sys.stdout.write("Hello World\n")
which would have to be written like:
dummyvar="Hello World\n"
sys.stdout.write(dummyvar)

The hard part comes in determining what you want to
f(x, x.y, x.y.z, x.y.z.t)

Cheesch! I will consider that by christmas :-)

Especially, if x happens to be an object that is readonly (throws just
exceptions upon __setattr__ :) )

Or better even:
f(__debug__)
(__debug__ happens to be 100% readonly variable, because it changes the
way the compiler works :)

Andreas

Tim Gahnström /Bladerman

2002-07-27 13:19:46 UTC

"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

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

Tim Gahnström /Bladerman

2002-07-26 12:36:53 UTC

Hi
<<Essence of question>>
Is there a guide or a recomended way to "get to know" the source code to the
python interpreter?

<<Some helping background>>
I am creating a new language and an IDE intended for beginners. This is my
CS master thesis. I plan to use Python as primary language and the Python
interpreter as my interpreter. I will probably need to make quite a few
changes to the the interpreter to make the language behave the way I want,
and I will need to monitor the state of the interperter for debugging
purposes

<<Some really uininteresting background>>
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
what I have set out to create. I have designed the language I want to creat
and I have made the first draft of the IDE using Tkinter but I have a big
problem with the python source. It is quite extensive and I am not one of
those people that can have a look at a million lines of code and se the
connections.
The best would be, ofcourse, some UML documentation but I would also be
happy if I found a small description och what code is where, how to
compilem, design thoughts or anything like that. A lot of projects have "a
small guide for wannabe developers" but I havn't found anything like that
for this project. Not on the website and not in any FAQ.
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.

<<Thoughs that is of no interest to anyone that might answer my real
question>>
I have given it some thought and think that I can make alot of my changes by
preprocessing the code and turn it into correct python code before I send it
to the interpreter but that is not viable for everything so I will need to
look into the sources anyway. For instance the graphics libary I plan to
create I can do all in Python (speed is not an issue).
Any thoughts on the subject is ofcourse more then welcome and I am sure I
will come back with other questions but the first thing I need is a guide to
the Python interpreter sources.

Thanks

Tim Gahnstr?m

Terry Reedy

2002-07-28 22:09:18 UTC

"Tim Gahnstr?m /Bladerman" <tim at bladerman.com> wrote in message

ask a complete novice what he think this peace of code will do
#Here is the program
x=3
inc(x)
print x
#Bellow is al the function deffinitions
x= x+1

Your example is deceptive and biased because you use the same name for
the global and local vars, which is known to be confusing to complete
novices, let alone those with more experience. They will tend to
think that they are the same thing and give the wrong answer on the
basis of that misconception. Much better is

def inc(temp):
temp = temp+1

You might have to tell him about assignment but not much else for

him to

understand that this program will print 4

I tried your experiment with my wife, who is not even a novice w/r/t
computer programming. She first refused to answer. When she
(mis)interpreted 'inc(x)' as acting like a calculator key press, with
an implicit 'x=' prefixed, she thought '4'. When I 'inlined' the
function call and rewrote the program as

x = 3
t = x
t = t+1
print x

she immediately said '3'.

To get 4 correctly (rather than on the basis of misunderstanding), one
would have to inline inc (mentally or actually) as something like

x = 3
t = &x
*t = *t+1
print x

but no novice would think of this and few would grok it. (Those who
do are, of course, passing beyond novicehood.)

If you want to use Python as if it were a calculator, write your
functions to return a value, run in interactive mode, and use '_'
instead of 'x' as the name of the default and automatically displayed
variable. All expressions get an implied '_=' prefix just like the

def inc(t): return t+1

...

inc(_)

4

Terry J. Reedy

Tim Gahnström /Bladerman

2002-07-29 08:29:41 UTC

"Terry Reedy" <tjreedy at udel.edu> skrev

Post by Terry Reedy
"Tim Gahnstr?m /Bladerman" <tim at bladerman.com> wrote in message

ask a complete novice what he think this peace of code will do
#Here is the program
x=3
inc(x)
print x
#Bellow is al the function deffinitions
x= x+1

You might have to tell him about assignment but not much else for

him to

understand that this program will print 4

I tried your experiment with my wife, who is not even a novice w/r/t
computer programming. She first refused to answer. When she

Hmm,
Okey. Now we are running two discussions in paralell. One about if it is
possible and one about if it is good.

Maybe I am wrong in both cases, the first case is getting to seem obvious
but I am not really convinced yet about the second. I will have to sit down
and think it over a little.
But either reason is enough for me to drop the feature.
There is actually a third reason to drop it that I have had in my mind since
I started. It is good to have it much similar to how most languages work
today, namely by CBV.

By the way, I won't even dare to tell you guys about the mess I have thought
out for the way I intend to handle objects, classes and imports :-)

The thesis is not about making a CBR language but make an IDE with debugger
for a language suited for novices.

Tim

Kristian Ovaska

2002-07-30 08:06:17 UTC

Post by Tim GahnstrÃ¶m /Bladerman
The thesis is not about making a CBR language but make an IDE with debugger
for a language suited for novices.

Well, you've got the right language. I think Python is one of the
easiest languages to learn. It's precessor, ABC, was actually designed
to be a teaching language, I think.

I have switched to using Python (in a slighty pseudoish way) as my
pseudo language, and people can read it fine even if they've never
seen Python code before.

Someone has said, "Python is it for imperative languages", and I have
to agree. Like many programmers, I used to dream about designing my
own (imperative) language, but now I have to admit that my dream
language would look too much like Python to be designed. Damn Python!

--
Kristian Ovaska <kristian.ovaska at helsinki.fi>

Tim Gahnström /Bladerman

2002-07-28 19:23:51 UTC

"Martin v. Loewis" <martin at v.loewis.de>

when it comes to calling functions it will look like this
x=3
a=2
setTo3(a)

I must say thankyou verry much!!!

Not maybe for the solution, but for the effort to see solution instead of
just trying to spot things that make it "impossible"
It is fairly rare that you stumble upon such people (just try to talk to a
random university professor :-))

def __init__(self, value): self.value = value
def assign(self, value): self.value = value

The solution you outlined will ofcourse work for this particular example,
but the problem is that I want all this mess to be invissible to the user.
But maybe I can use it anyway. As I have said several times, I havn't yet
gotten aquainted with everything yet som maybe this is not possible.

The thing I have on my mind is (maybe this is what you meant to) that maybe
I can change the parser a little so that it sees everything as a subclass of
Refference. Then I just change the asignmentpart of the interpreter to use
.assign() instead of whatever hapens now.

I really have a hard time to explain what I mean here but I think I want a
statement like this:
a=2
to be parsed to
a.assign(Refference(2))

Do you think a solution like that be possible?
Anyway, even if this doesn't work out I am very gretfull for your effort to
see a solution to a tricky problem.
A problem might ofcourse be that this will screw the possibilities to use
the python library wich is not an option...

Tim

Alex Martelli

2002-07-26 14:36:58 UTC

Post by Tim GahnstrÃ¶m /Bladerman
Hi
<<Essence of question>>
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,
and you can complement them with e.g. my tutorial on the Europython site,
my articles in the "Py" zine, examples on the Cookbook, Bradley's
appendix in his "Essential Reference" book, etc, etc), it's not that
big a deal. Counting in each case empty and comment lines too, 90k
lines are in Modules/*.c -- 90 or so modules with a median of about
600 lines, mostly nice and easy; 39k lines in Objects/*.c, 30 or so
objects with a median of about 740 lines, nothing terrible; 3600 in
Parser/*c, admittedly nastier but the modules ARE small, median is
153 lines; 26K lines in Python/*.c (net of the dynload* stuff),
42 modules of median 150 lines.

There are a few tough places, some of which (e.g. the RE module) you
can probably skip, some (Python/compile.c, Python/ceval.c ...) not.

Once you ARE familiar with the C API, and thus with the object
implementations that after all do follow it, I suggest that for
the rest of the core you take a "flow" approach -- how is Python
source transformed into execution. I.e., compilation into bytecode,
and interpretation of bytecode. Those are nasty, particularly (as
of 2.2.1) the compilation. Then you can look at other more
marginal nasties such as garbage collection &c.

Post by Tim GahnstrÃ¶m /Bladerman
<<Some helping background>>
I am creating a new language and an IDE intended for beginners. This is my
CS master thesis. I plan to use Python as primary language and the Python
interpreter as my interpreter. I will probably need to make quite a few
changes to the the interpreter to make the language behave the way I want,
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.

Modification is of course another kettle of fish:-).

Two mostly separate issues, I think -- the really good IDE is pretty
uncontroversial (if really good:-), the mods WILL get you flames:-).

Post by Tim GahnstrÃ¶m /Bladerman
what I have set out to create. I have designed the language I want to
creat and I have made the first draft of the IDE using Tkinter but I have
a big problem with the python source. It is quite extensive and I am not
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.

Post by Tim GahnstrÃ¶m /Bladerman
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:-). "redirect output" is a mystery -- Python's
own output is highly redirectable, what more is needed? Case
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).

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

Anyway, I think that to implement call by reference you
will have to touch just about every one of 300 source files.

I suggest you consider "value/copy-return" as an alternative:
newbies can't tell the difference (except for the performance
hit, but in Python, as you'd be copying references, that
should be slight) and you could handle it with 1/10th the
hassle of pass-by-reference. Basically, you can widen the
information in a frame about the arguments, to record the
'sources, thus destinations' of each argument (that's the
hard part of course, since you need to make some tough
decisions, but still, doable); when you're about to
dismantle the frame on exit, copy back the changed value
of arguments (selectively, so you don't change the "2",
but that's easy).

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)

when f changes its 2nd argument, should that in turn
change the 3rd and 4th appropriately and implicitly too?
What if some of attributes y, z and t are obtained by
__getattr__ or its equivalent? And similar questions
for items vs attributes.

Algol 60 specified "call by name" -- easiest to explain,
hellish to implement when you consider such issues as
items, e.g.
i = 0
print f("ciao"[i], i)
with
def f(c, i)
i = i + 1
return c
should print "i" according to call-by-name semantics.
Call by value/copy-return is much easier to implement.
Call by reference is a sort of compromise that's more
or less inevitable for performance reasons when a
language has value (rather than reference) semantics,
and indeed that's what Fortran mostly did -- but
having reference semantics trying to perch call by
reference on top of it seems really precarious.

Alex

Tim Gahnström /Bladerman

2002-07-28 19:23:51 UTC

"Andreas Kostyrka" <andreas at kostyrka.priv.at

the sidefects of it. An other possibility would be to generate a good
looking errormessage. Because it is likely a mistake.

sys.stdout.write("Hello World\n")

No I don't
I wouldnt prevent it in every case, just when the parameter is actually
assigned a value by the function.
But this is not an issue since I wont do it that way...

Tim

Tim Gahnström /Bladerman

2002-07-27 13:19:45 UTC

"Alex Martelli" <aleax at aleax.it>

Post by Tim GahnstrÃ¶m /Bladerman
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

Post by Alex Martelli
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.

Post by Alex Martelli
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

Post by Tim GahnstrÃ¶m /Bladerman
and I will need to monitor the state of the interperter for debugging
purposes

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.

Post by Alex Martelli
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.

Post by Tim GahnstrÃ¶m /Bladerman
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 :-)

Post by Tim GahnstrÃ¶m /Bladerman
one of those people that can have a look at a million lines of code and se

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

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.

Post by Alex Martelli
"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.

Post by Alex Martelli
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.

Post by Alex Martelli
"Call by reference" I gotta see. Just for fun, do it like
x = x + 1
inc(2)
print 2
should of course print '3'.

Post by Alex Martelli
The hard part comes in determining what you want to
f(x, x.y, x.y.z, x.y.z.t)

Cheesch! I will consider that by christmas :-)

Thanks alot!

Tim

Andreas Kostyrka

2002-07-28 14:45:29 UTC

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

Michael Hudson

2002-07-26 13:03:54 UTC

Post by Tim GahnstrÃ¶m /Bladerman
Hi
<<Essence of question>>
Is there a guide or a recomended way to "get to know" the source
code to the python interpreter?

Don't think so. I've had thoughts of writing one, but never got far
enough into it for it to be worth showing anyone else. It seems to be
difficult pedagogically to explain one area without requiring
knowledge of areas not yet covered.

OTOH, the interpreter source is mostly clearly layed out, well written
C. There are dragons in some areas (bits of the import process,
coercions), but not many.

Oh, and the compiler's not that nice either. What sort of changes are
you thinking of? You may be better off using the compiler package in
the standard library, or at least leveraging it.

Post by Tim GahnstrÃ¶m /Bladerman
<<Some really uininteresting background>>
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
what I have set out to create. I have designed the language I want to creat
and I have made the first draft of the IDE using Tkinter but I have a big
problem with the python source. It is quite extensive and I am not one of
those people that can have a look at a million lines of code and se the
connections.

The Python source also has the property that you don't need to read
all of it to get the big picture.

Post by Tim GahnstrÃ¶m /Bladerman
The best would be, ofcourse, some UML documentation

Of course? Um, dissent from here...

Post by Tim GahnstrÃ¶m /Bladerman
but I would also be happy if I found a small description och what
code is where,

Well, the interpreter mainloop is in Python/ceval.c, object type
implementations are in Object/*.c, ...

Post by Tim GahnstrÃ¶m /Bladerman
how to compilem,

compiling is easy, at least on Unix or Win32.

Post by Tim GahnstrÃ¶m /Bladerman
design thoughts

Reading Include/object.h (and maybe other headers -- objimpl.h?) might
give some clues.

Post by Tim GahnstrÃ¶m /Bladerman
or anything like that. A lot of projects have "a small guide for
wannabe developers" but I havn't found anything like that for this
project.

There's http://www.python.org/dev/, but there's nothing of the sort
you're asking for here, really.

Post by Tim GahnstrÃ¶m /Bladerman
Not on the website and not in any FAQ.
Things I want to change is for example, everything should be "call by
refferense",

That may be very hard. If you want things like this:

def f(x):
x += 1

i = 2
f(i)
i --> 3

then you have problems.

Post by Tim GahnstrÃ¶m /Bladerman
it shall not by case sensitive,

Easy.

Post by Tim GahnstrÃ¶m /Bladerman
redirect output,

Probably easy. Not quite sure what you mean here.

Post by Tim GahnstrÃ¶m /Bladerman
better errormesages,

Examples? Feel free to contribute these back to the project...

Post by Tim GahnstrÃ¶m /Bladerman
etc, etc.
<<Thoughs that is of no interest to anyone that might answer my real
question>>
I have given it some thought and think that I can make alot of my changes by
preprocessing the code and turn it into correct python code before I send it
to the interpreter but that is not viable for everything so I will need to
look into the sources anyway. For instance the graphics libary I plan to
create I can do all in Python (speed is not an issue).
Any thoughts on the subject is ofcourse more then welcome and I am sure I
will come back with other questions but the first thing I need is a guide to
the Python interpreter sources.

Have you written any Python extensions in C? That gives you a pretty
good idea of what is going on in a certain, important area.

Cheers,
M.

--
I never realized it before, but having looked that over I'm certain
I'd rather have my eyes burned out by zombies with flaming dung
sticks than work on a conscientious Unicode regex engine.
-- Tim Peters, 3 Dec 1998

Terry Reedy

2002-07-27 17:39:06 UTC

"Tim Gahnstr?m /Bladerman" <tim at bladerman.com> wrote in message

I want to make all variables mutable.

In a real sense, Python does not have variables. It has objects, each
of which has 1 or more named or unnamed references thereunto. Which
do *you* think of as variables: objects, references, or names? If
objects, you should look to another language since immutability of
certain types of objects is an integral part of Python (the operation
of dicts, for instance.) I believe most people think of variables as
names, which works best (fewest surprises) within the Python data
model when bound to immutable data types. For example:

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

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 my view of CBR, maybe that is not the correct definition .

To me, call by reference means that the function gets a reference to
the actual argument instead of an anonymous copy. However, for Python
immutables, the effect is the same, except for avoiding the creation
and usual destruction of the copy.

and I don't need CBR

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

Terry J. Reedy

Martin v. Loewis

2002-07-27 22:13:17 UTC

when it comes to calling functions it will look like this
x=3
a=2
setTo3(a)

Others have already suggested that this will be impossible to
implement, but I guess I can't stop you from trying, so I won't.

Instead, I suggest that this is already possible with a slightly
different notation

def setTo3(x):
x.assign(3)

a=Reference(2)
setTo3(a)

All this requires is

class Reference:
def __init__(self, value): self.value = value
def assign(self, value): self.value = value

Regards,
Martin

Tim Gahnström /Bladerman

2002-07-27 19:15:00 UTC

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.

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

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.

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?

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

Tim Gahnström /Bladerman

2002-07-28 19:23:51 UTC

"Andreas Kostyrka" <andreas at kostyrka.priv.at>

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

Hmm... havn't thought about it yet but I dont think it will be a problem. It
might be a mess to explain but I don't really think it will be a problem.
def f(x):
x=x+2
if x>100:
return
f(x)

The result of x is obvious but it will probably be a mess to make that
happen in the interpreter. I don't know, it will ofcourse depend on how / if
I implement this CBR feature.

Post by Andreas Kostyrka
[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.]

Deffinitley agree. Recursion will be possible and it will work in a
straightforward way. Recursion is still possible in languages that support
CBR so I am sure that it is possible.

Well I am getting more and more aquainted to agree with you the more I hear
about the Python datamodel.
I didn't study that before I choose Python, I must admit that. I knew the
syntax and that it was a really good and extendable interpreter. That is why
I choose it.

Post by Andreas Kostyrka
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.

That, ofcourse is impossible and won't happen. Still, if this is such an
utterly impossible feature I will just dropp it. That is not a fundamental
thing.

Forget it :)

Cough, cough... may I throw out a wild guess... you are on the higher end of
the age scale right? ;-)

Post by Andreas Kostyrka
Write some small (~1000KLOC) applications in Python, do some data
manipulation stuff, and then reconsider your project ;)

Actually that is what I am doing... I am writing a small application with
datamanipulation stuf :-)

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

Some people chose easy master thesises that they wouldn't show to a future
employer even with a gun to there head. (they usuallu succed)
Some people chose a project that have the possibillity of being awesome if
it is finished as the utopi is in there head.
I guess I am in the second group and might fail with a splash and I migh
also succed by an inch and end up haiting my project, but atleast I tried .

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

Well that is your opinion not mine.

ask a complete novice what he think this peace of code will do

#Here is the program
x=3
inc(x)
print x

#Bellow is al the function deffinitions
def inc(x):
x= x+1

You might have to tell him about assignment but not much else for him to
understand that this program will print 4
I think it is intuituve you don't I am fine with that but I dont agree.
But on the other hand, I am not ready to work that much to get it my way.

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.

I am just trying to see possibilities and give ideas, maybe someone will see
a possible solution.

Imagin this:
A whole lot of talented programmers is presented with an idea about creating
a language that works like Python except that it is uses CBR. Al of them
agree that it is impossible without rewriting the whole interpreter AND the
Python library.

To me can only mean two things.
1. It really is impossible
2. We have the programmers to blame for the "dot com" crash. :-) (means they
are narrow minded)

I don't know wich one is correct and I guess I am not (yet) ready to bet my
Master thesis on the second one.

Tim

Neil Schemenauer

2002-07-26 17:58:55 UTC

Post by Tim GahnstrÃ¶m /Bladerman
Is there a guide or a recomended way to "get to know" the source code to the
python interpreter?

Not that I know of. Here are a few pointers:

* Python/ceval.c:eval_frame is the heart of the virtual machine. This
is were most of the work is done. Use the 'dis' module to
disassemble bytecode to get an idea of how the VM works. For
... return 10 + 20
...

import dis
dis.dis(foo)

0 SET_LINENO 1

3 SET_LINENO 2
6 LOAD_CONST 1 (10)
9 LOAD_CONST 2 (20)
12 BINARY_ADD
13 RETURN_VALUE
14 LOAD_CONST 0 (None)
17 RETURN_VALUE

* The data structures in Include/object.h are key. You should
study PyObject, PyVarObject and PyTypeObject.

* Most builtin objects live in the 'Objects' directory. There is
usually one file for each object. Some objects have header
information in 'Include'.

* The parser lives in 'Parser' and the compiler is in 'Python'. I
would recommend studying the compiler written in Python (in
Lib/compiler) rather than the one written in C.

HTH,

Neil

Tim Gahnström /Bladerman

2002-07-27 13:19:45 UTC

"Terry Reedy" <tjreedy at udel.edu>

Things I want to change is for example, everything should be "call
refferense",

Alex Martelli

2002-07-27 14:50:52 UTC

"Terry Reedy" <tjreedy at udel.edu>

Things I want to change is for example, everything should be "call
refferense",

I want to make all variables mutable.

Variables are just names, "post-it" tags that ate weakly attached
to an object at any given time. They could (perverting terms) be
said to be "mutable" in that nothing forbids detaching the post-it
from one object and attaching it to another one (or just detaching
it, that's what the del statement is for).

If by "variables" you also want to mean structured names, i.e,
x.y to mean attribute y of object x, right now it's up to x's type
if attribute y is 'mutable' (reattachable, detachable, attachable
at all). x's type may define for the purpose methods named
__setattr__ and __delattr__, or in Python 2.2 "properties" (and
potentially other descriptors) that defines what it means to try
to attach an object to the name x.y. When x's type is a class and
does not do anything about it, by default x carries around a dict
and x.y is 'mutated' by acting on x.__dict__['y'].

But the mutable/nonmutable distinction normally applies to OBJECTS.
Python, like Java, uses nonmutable strings for the simplicity and
clarity they bring (but Python was there first, just as it was for
the "reference semantics" above summarized... well, not _first_, but
definitely before Java:-).

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

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?

It _isn't_ done! Python functions don't go around detaching and
reattaching the names held by their callers, any more than Java
or C ones do such intrusions in their callers' namespaces. Java
is closer to Python -- reference semantics: names are just post-it
notes. C uses a more complicated and ancient way to look at
things, closer to the way a computer works internally - names are
"boxes" with values "inside" them (value semantics). [Java makes
things more complicated by having SOME types held in boxes, but
that's just Java being cranky and complicated in the claimed name
of efficiency].

One way to look at things is: passing an argument is exactly like
assigning to a variable. I.e., say that you have:
def inc(y): ...(something)...
and you all inx(x).
This is like doing:
y = x
After such an assignment, do you figure that there are things
you can to do *y* that make *x* be connected to another object?

There aren't. x and y are not all that tighly connected. They
both refer to the same object, that's all. You can make y
refer to another object, but that won't affect x. Do you
think it SHOULD? Would you EXPECT, say:
y = x
y = 23
to rebind *x* to refer to 23 too?

Now, it seems that what you want is: the y = 23 MUST rebind
x IF it happens in ANOTHER function named 'inc', but must keep
not rebinding x if it happens in the same function where x
was also defined. I.e., the equivalence of argument passing
to assignment must be broken, and argument passing must in some
way create a far tighter binding between the source and
destination names than assignment does.

This is a very substantial complication to the language's
definition, of course -- two ways to "associate", one the
existing assignment-and-argument-passing way that must stay
only connected to assigment syntax, the other a new and
tighter association, that must take over argument passing
syntax. Surely you realize that the more separate concepts
there are, the harder a language is to teach, particularly
to beginners. With Python, I can explain to a bright
beginner ONCE that "the meaning of assignment is just like
that of argument passing" (if I've taught argument passing
first -- or else, the reverse, that works too), and I'm
done. 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 my view of CBR, maybe that is not the correct definition and I
don't need CBR.

I'm sure you don't (need it, that is), but you do seem to
keenly WANT it, which is another issue. value/copy-return
is a simpler variant of CBR that, while still more complex
than what Python does, might be easier for you to put in
practice.

There ARE differences, though. With CBR things happen
magicaly and implicitly, as in:

def f(x, y):
x = "ciao"
print y

when called as f(a, a) must presumably print "ciao", since
the rebinding of x has mysteriously rebound a which in
turn is ALSO connected to y. With value/copy-return, just
as with the simplest approach (i.e., Python's), f(a,a)
will print whatever a contains on call; v/c-r adds one
implicit rebinding at the end. Of course it IS still a
mess, e.g. what does happen after g(a,a) when:

def g(x, y):
x = "one"
y = "two"

...? With Python's semantics, nothing (simplest). With
CBR semantics, a is presumably now worth 'two'. With
v/c-r it's hard to say, since both copies back to a are
done when g terminates and it's not clear how to sequence
them in cases of conflict (even diagnosing the conflicts
may not me trivial).

What a mess. Still, you DO keenly want this mess (or some
variant thereof), therefore, good luck in extricating
yourself from it!

Alex

Edward K. Ream

2002-07-26 20:17:18 UTC

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

Edward K. Ream

2002-07-26 20:35:20 UTC

Actually, the documentation for PyDict_GetItemString
is at http://python.org/doc/current/api/dictObjects.html#l2h-530

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

Tim Gahnström /Bladerman

2002-07-27 13:19:46 UTC

"Neil Schemenauer" <nas at python.ca>

Post by Neil Schemenauer

Post by Tim GahnstrÃ¶m /Bladerman
Is there a guide or a recomended way to "get to know" the source code to the
python interpreter?

* Python/ceval.c:eval_frame is the heart of the virtual machine. This
is were most of the work is done. Use the 'dis' module to

There I guess I will spend most of my coming days :-)

Post by Neil Schemenauer
disassemble bytecode to get an idea of how the VM works. For

That was interesting, definitley a feature I must look at a little.

Post by Neil Schemenauer
* The data structures in Include/object.h are key. You should
study PyObject, PyVarObject and PyTypeObject.

Maybe there I can find a cheap way to make everything mutable.

Post by Neil Schemenauer
* Most builtin objects live in the 'Objects' directory. There is
* The parser lives in 'Parser' and the compiler is in 'Python'. I

Thanks alot. It is fasignating how many people wanted to help out!

Tim

Terry Reedy

2002-07-26 15:48:11 UTC

Things I want to change is for example, everything should be "call by
refferense",

Alex Martelli

2002-07-27 15:01:20 UTC

Tim Gahnstr?m /Bladerman wrote:
...

Things I want to change is for example, everything should be "call by
refferense",

x += 1
i = 2
f(i)
i --> 3
then you have problems.

That is exactly what I want to have, that is more intuitive I think and I
don't think it must be that hard either. It is not a speed issue so it

It's hard to believe that you can hold such opinions if you
understand Python. Or if you have really thought about the
issues, such as -- what happens when two or more arguments
are involved and interact? E.g., they're the same variable,
or an index and an indexing that uses it, etc...?

def f(x, y):
x = 23
y = 45

and:

i = 7
f(i, g[i])

We understand that you keenly want i to be 23 as "more intuitive"
(I've never seen a programming beginner tackling Java or Python
as a first language expect that -- the "intuitiveness" appears to
come entirely from the way some OTHER languages behave:-), but
what should "intuitively" be the item of g that is affected?

In CBR languages, it's invariably g[7] that gets the 45, and THAT
baffles every beginner I've ever met. Affecting g[23] would
be "call by NAME" and indeed very intuitive, but such a living
hell to implement that since Algol-60's demises I doubt any
language has gone down that route.

Post by Tim GahnstrÃ¶m /Bladerman
must not be a true CBR. I will probably figure out some ugly hack to make
it seem like CBR.
Maybe look into value/copy return as Alex Martelli mentioned. What I want
is not really CBR but the, from Ada known "in out parameters" or the
Pascall "var parameter".

Ada and Pascal have value semantics. x = y makes a COPY of the
stuff held in a "box" named y, into a "box" named x. Python has
no boxes, it has post-it notes -- reference semantics. That
changes everything...

Alex

Michael Hudson

2002-07-29 09:41:14 UTC

Post by Tim GahnstrÃ¶m /Bladerman
I noticed, but thought that I just had missed it. I thought there
must be some where for such a large project. But the problem is
ofcourse ever present, "nobody likes to do documentation"

Python has masses of documentation, but most of it is aimed at Python
programmers, not people who want to hack on the core...

Things I want to change is for example, everything should be "call by
refferense",

x += 1
i = 2
f(i)
i --> 3
then you have problems.

That is exactly what I want to have, that is more intuitive I think and I
don't think it must be that hard either.

I don't want to get into an argument with you -- but you're wrong ;-)

Have a look at this page I wrote a while's back:

http://starship.python.net/crew/mwh/hacks/objectthink.html

which explains how Python's object work -- I don't think you can make
call by reference work without changing this model, and then you don't
have Python any more.

FWIW, the way Python objects work is very similar to Lisp and Scheme
(and just similar to Java).

Cheers,
M.

--
MAN: How can I tell that the past isn't a fiction designed to
account for the discrepancy between my immediate physical
sensations and my state of mind?
-- The Hitch-Hikers Guide to the Galaxy, Episode 12

Fearless Freep

2002-07-29 16:51:28 UTC

Post by Michael Hudson

Things I want to change is for example, everything should be "call by
refferense",

x += 1
i = 2
f(i)
i --> 3
then you have problems.

That is exactly what I want to have, that is more intuitive I think and I
don't think it must be that hard either.

I don't want to get into an argument with you -- but you're wrong ;-)
http://starship.python.net/crew/mwh/hacks/objectthink.html
which explains how Python's object work -- I don't think you can make
call by reference work without changing this model, and then you don't
have Python any more.
FWIW, the way Python objects work is very similar to Lisp and Scheme
(and just similar to Java).

I was making the argument a few days ago that the inability to do just
that was why Python was more scalable than TCL.

The problem when you have something like

foo (x)

where x can be reassigned as above, is that you can have unintended
consquences.

if you have code like

foo(x)
print x

and x does not come out with the value you expect, you know that it
was not changed in foo(), so you don't have to investigate the
implementation of foo() to determine if it changed x

x = foo(x) It's obvious you are changing x
y = foo(x) It's obvious you are not changing x

if you allow

def foo(i)
i = i + 1

then you lose the ability to look at the clients of foo() and know
what potential consequences there are.

I think Ada got it right with the "in", "out" and "in out" parameter
declarations; short of that, I don't think you should be able to
re-assign parameters to functions, it add complexity to reading and
deciphering code

Take care,
Jay O'Connor
http://www.r4h.org/r4hsoftware

Skip Montanaro

2002-07-29 03:03:48 UTC

http://manatee.mojam.com/pyvmwiki/

David> Even better, how about putting it on the Python org wiki?

Fine, except for the fact that the Python.org Wiki is down at the
moment... ;-)

Skip

Tim Gahnström /Bladerman

2002-07-29 08:29:41 UTC

"Skip Montanaro" <skip at pobox.com> skrev i meddelandet

To me this seems like a verry good idea.
I will have a look at it when I come back home again in a few days and maybe
post my thoughts.

Thanks

Tim

Skip Montanaro

2002-07-30 15:36:20 UTC

Chris> Just a remark: All the icons appear to be broken, for example: <a
Chris> href="/pyvmwiki/HelpContents"><img
Chris> src="/pyvmwiki/img/moin-help.gif"

Yes, thanks. I had muffed the moin_config.py file. Should be okay now.

Skip

Christian Tismer

2002-07-29 11:09:00 UTC

Nice starter! I'd like to contribute.

Looking into the HTML I saw you are using moinmoin :-)

Just a remark: All the icons appear to be broken, for example:
<a href="/pyvmwiki/HelpContents"><img src="/pyvmwiki/img/moin-help.gif"

All the images are probably in a different folder.

cheers - chris

--
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

Andreas Kostyrka

2002-07-28 14:45:08 UTC

Post by Tim GahnstrÃ¶m /Bladerman
I noticed, but thought that I just had missed it. I thought there must be
some where for such a large project. But the problem is ofcourse ever
present, "nobody likes to do documentation"

Well, start with the embedding/extending documantation.

Post by Tim GahnstrÃ¶m /Bladerman
Maybe look into value/copy return as Alex Martelli mentioned. What I want is
not really CBR but the, from Ada known "in out parameters" or the Pascall
"var parameter".

var parameters are true call by reference. And it would make no sense in
a language design, because call by value semantics have cleaner
semantics.

f(i) with general reference semantics have unnice property, that I know
nothing about i after the call. Now there is nothing in the python
syntax that would make specifing which parameters should be reference
passed.

Additionally, the most important use CBR is passing out multiple return
values, which is obviously not needed in python:
def func(x,y,z):
return (x+1,y+1,z+1)
a,b,c=func(d,e,f)

Probably easy. Not quite sure what you mean here.

sys.stdout=open("somefile","w")
sys.stdout=cStringIO.StringIO()

Post by Tim GahnstrÃ¶m /Bladerman
Didn't really mean anything briliant there, it was just small things that
poped out of my head while I was writing.
I meant I want all output (text, graphics, buttons, etc) in a certain window
in the IDE I am creating.

better errormesages,

Examples? Feel free to contribute these back to the project...

But that is exactly not correct:
max(1,2)
max(1,2,3,4,5,6)
max((1,2,))
max([1,2,3,4,])

are all legal.
max(someObject)
might also be legal, if someObject is a user made list like object.

Post by Tim GahnstrÃ¶m /Bladerman
File "<pyshell#8>", line 1, in ?
TypeError: min() or max() arg must be a sequence"

Well, this at least correct. (arg must be a sequence.)
While your nice message above is misleading.

Andreas

Skip Montanaro

2002-07-28 20:59:08 UTC

Something occurred to me last night... How about a PyVM Wiki? Once the
content is there we could see about organizing it in a suitable form for
inclusion in the standard document set.

I started things off with some notes I wrote a few months ago:

http://manatee.mojam.com/pyvmwiki/

--
Skip Montanaro
skip at pobox.com
consulting: http://manatee.mojam.com/~skip/resume.html

David LeBlanc

2002-07-28 21:27:41 UTC

Even better, how about putting it on the Python org wiki?

David LeBlanc
Seattle, WA USA

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Skip Montanaro
Sent: Sunday, July 28, 2002 13:59
To: Andreas Kostyrka
Cc: Tim Gahnstrom /Bladerman; python-list at python.org
Subject: Re: Guide to the python interp. source?

Something occurred to me last night... How about a PyVM Wiki? Once the
content is there we could see about organizing it in a suitable form for
inclusion in the standard document set.
http://manatee.mojam.com/pyvmwiki/
--
Skip Montanaro
skip at pobox.com
consulting: http://manatee.mojam.com/~skip/resume.html
--
http://mail.python.org/mailman/listinfo/python-list

Tim Gahnström /Bladerman

2002-07-28 19:23:50 UTC

"Andreas Kostyrka" <andreas at kostyrka.priv.at>

Post by Tim GahnstrÃ¶m /Bladerman
I noticed, but thought that I just had missed it. I thought there must be
some where for such a large project. But the problem is ofcourse ever
present, "nobody likes to do documentation"

Well, start with the embedding/extending documantation.

Will do that, it seems like a good start!

var parameters are true call by reference. And it would make no sense in
a language design, because call by value semantics have cleaner
semantics.

I respect your opinion but that doesn't mean that I don't agree with it.
I don't think that clean semantics is all that matters in a language design
and I dont hink it is more intuitive.
But I might verry well change my semantics to a call by value because there
seems to be an imense amount of work to fix it.

Post by Andreas Kostyrka
f(i) with general reference semantics have unnice property, that I know
nothing about i after the call. Now there is nothing in the python

That might verry well be an unnice property in some (most) situations but
not in this case (my OPINION).

Post by Andreas Kostyrka
Additionally, the most important use CBR is passing out multiple return

That is one reason, another is that it might be faster some times, there may
be more reasons. (Why do Python have mutable objects? They are not really
needed and you dont know what will happen with them when you send them to a
funcion)