Guide to the python interp. source?

[Tim Gahnström /Bladerman]

"Andreas Kostyrka" <andreas at kostyrka.priv.at>
>Am Sam, 2002-07-27 um 15.19 schrieb 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!

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

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.


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

>Additionally, the most important use CBR is passing out multiple return
>values, which is obviously not needed in python:

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)


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

>But that is exactly not correct:

It is not wrong either. It is not a complete list of possible errors but it
is the most probable. The plan is to make better errormessages to a novice
programmer not to make a list of all possible things...

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

and mybe the novice using this program is not a novice at all but some
überhacker from Mars that never ever will make an error...
Sorry... what I mean is that it was an exmple error message I wrote there
and it was not complete and not even intended to be complete, not even in
the actuall program. It is intendet to present the novice with the most
probable error.


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

Where you never ever a beginner asking why the errormessages were so utterly
cryptic?
What I wrote were not wrong, it mentioned the two most likely things.
It might not have been the best example but it ilustrated what I meant wich
was what asked for.

Tim