IsString

[Mike Meyer]

But neither is it call by reference. If it were call by reference, I could
write something like this:

def increment(n):
"""Add one to the argument changing it in place."""
# In Pascal, I would need the var keyword to get this behaviour,
# but Python is call by reference so all variables are passed
# by reference.
n += 1

x = 1
increment(x)
assert x == 2

but that doesn't work in Python either.

Yes, it doesn't work, but the reason it doesn't work isn't because
Python doesn't do call-by-reference.

So Python behaves demonstrably different from BOTH call by value and call
by reference. Consequently, it is neither of them.

Right. *Python* behaves differently. That's not the same thing as
Python's calling behaving differently. If you choose objects that are
behave the same in both languages, Python behaves *exactly* like
call-by-reference.

You can show the same difference in behavior between Python and C (for
example) without using a function call.

Here's C:

#include <assert.h>

main() {
int i, *ref ;
i = 1 ;
ref = &i ; /* Save identity of i */
i = 2 ;
assert(ref == &i) ;
}

This runs just fine; i is the same object throughout the program.

Traceback (most recent call last):

Blows up - i is no longer the same object.

Python does call by reference, which means that it passes pointers to
objects by value. C is call by value, faking call by reference by
passing reference values. The real difference is that in C, you can
get a reference to a variable to pass, allowing you to change the
variable. In python, you can't get a reference to a name (one of the
reasons we call them "names" instead of "variables"), so you can't
pass a value that will let the called function change it.

<mike

 

[Steven D'Aprano]

Right. *Python* behaves differently. That's not the same thing as
Python's calling behaving differently. If you choose objects that are
behave the same in both languages, Python behaves *exactly* like
call-by-reference.

This would possibly be a valid argument if Python
*only* had such objects that behaved the same in call
by reference languages, but it doesn't. It also has
objects which behave differently. Just because Python
can, in certain restricted circumstances, act like call
by reference doesn't mean it is call by reference,
because there are a whole swag of circumstances where
Python _can't_ act like call by reference.

You can show the same difference in behavior between Python and C (for
example) without using a function call.

Here's C:

#include <assert.h>

main() {
int i, *ref ;
i = 1 ;
ref = &i ; /* Save identity of i */
i = 2 ;
assert(ref == &i) ;
}

This runs just fine; i is the same object throughout the program.


Traceback (most recent call last):
File "<stdin>", line 1, in ?
AssertionError


Blows up - i is no longer the same object.

Your argument seems to me like some sort of reverse
bizarro "looks like a duck" argument: since Python
_doesn't_ behave like call by reference, it must _be_
call by reference.

Python does call by reference, which means that it passes pointers to
objects by value.

You are confusing the underlying implementation in C
with Python the language. I couldn't care less whether
the underlying implementation allows call by reference
or not. That is simply irrelevent to the question of
whether Python does call by reference.

Python doesn't have a pointer object type. There is an
implementation of Python written in pure Python. That
demonstrates that there is at least one implementation
of Python where it is demonstrably _not_ true that
Python "passes pointers to objects by value".

What do you think that does to your argument?

 

[Ben Sizer]

def modify_in_place(obj):
"""Modify an arbitrary object in place."""
obj = None

x = [1, 2, 3] # mutable object
modify_in_place(x)
assert x is None


Doesn't work either.

To be fair, this isn't because the function is not pass by reference,
but because the assignment operator reassigns the reference rather than
altering the referent, and thus modify_in_place doesn't actually
contain any modifying operations. With a good understanding of what
Python's assignment operator actually does, (I believe) you can view
Python as pass-by-reference without any semantic problems.

 

[Mike Meyer]

This would possibly be a valid argument if Python *only* had such
objects that behaved the same in call by reference languages, but it
doesn't. It also has objects which behave differently. Just because
Python can, in certain restricted circumstances, act like call by
reference doesn't mean it is call by reference, because there are a
whole swag of circumstances where Python _can't_ act like call by
reference.

You've got this exactly backwards. Every object in Python behaves the
same way as similar objects in call-by-reference lannguages. Those
languages have objects which have no analogue in Python. If you use
one of them as your example of what "call-by-reference" does, it will
of course have behavior that can't be reproduced in Python. That isn't
because Python isn't call-by-reference; it's because Python doesn't
have objects that behave like the one you're using for an example.

Your argument seems to me like some sort of reverse bizarro "looks
like a duck" argument: since Python _doesn't_ behave like call by
reference, it must _be_ call by reference.

You're right in that this doesn't demonstrate that Python has
call by referece. What it shows is that your example of why Python
isn't call by referencde is invalid: your example depends on an object
behavior that doesn't exist in Python, no matter what calling
convention it uses.

You are confusing the underlying implementation in C with Python the
language. I couldn't care less whether the underlying implementation
allows call by reference or not. That is simply irrelevent to the
question of whether Python does call by reference.
Python doesn't have a pointer object type. There is an implementation
of Python written in pure Python. That demonstrates that there is at
least one implementation of Python where it is demonstrably _not_ true
that Python "passes pointers to objects by value".
What do you think that does to your argument?

I think you're right in the first paragraph - that it's discussing the
implementation, and is thus totally irrelevant to the question of
whether or not python does call by reference.

To restate the first paragraph: Python's calling semantics are a
proper subset of call-by-reference. If the object passed has the same
behavior as it does in a call-by-reference lanuage, then the behavior
of the argument is the same as it is in the call-by-reference
language. You can argue that one of the missing things is crucial to
the definition of call by reference, in which case we disagree about
the meaning of call by reference, and we can stop there. Or you can
argue that there is some object in Python that behaves the same way in
both Python and a call by reference that does not behave the same way
when passed as an argument. I'm still waiting for an example of that.

<mike

 

[Tom Anderson]

in tom's world, the value of an object is the pointer to the object, not
the object itself,

If you meant "he value of a *variable* is a pointer to an object, not the
object itself", then bingo, yes, that's what it's like in my world.

so I'm not sure he can make sense of your explanation.

The explanation makes perfect sense - i think the names-values-bindings
terminology is consistent, correct and clear. It's just that i think that
the variables-objects-pointers terminology is equally so, so i object to
statements like "python is not pass-by-value".

tom

 

[Tom Anderson]

In the sense that a variable has various meta-informations (at least a
type)

No. In a statically typed language (or possibly only a manifestly typed
language), a variable has a type; in an untyped language, it doesn't.

while a Python name has no information. A Python name would be
equivalent to a C void pointer, it can mean *any*thing and has no
value/meaning by itself, only the object it references has.

Quite right - so it's also equivalent to a LISP, Smalltalk or Objective C
(to mention but a few) variable?

tom

 

[Tom Anderson]

You can show the same difference in behavior between Python and C (for
example) without using a function call.

Really? You certainly don't do that with the code below.

Here's C:

#include <assert.h>

main() {
int i, *ref ;
i = 1 ;
ref = &i ; /* Save identity of i */

Here, ref is a reference to a variable.

i = 2 ;
assert(ref == &i) ;

Here, you're comparing the addresses of variables.

}

This runs just fine; i is the same object throughout the program.

Here, ref is a reference to a value.

Here, you're comparing values.

Traceback (most recent call last):


Blows up - i is no longer the same object.

Right, because the two bits of code are doing quite different things.

Python does call by reference, which means that it passes pointers to
objects by value.

That's not what call by reference is - call by reference is passing
pointers to *variables* by value.

C is call by value, faking call by reference by passing reference
values. The real difference is that in C, you can get a reference to a
variable to pass, allowing you to change the variable. In python, you
can't get a reference to a name (one of the reasons we call them "names"
instead of "variables"), so you can't pass a value that will let the
called function change it.

Kinda. Here's a python translation of Steven's incrementing function
example:

def increment(n):
"""Add one to the argument changing it in place."""
# python (rightly) doesn't have references to variables
# so i will use a 2-tuple (namespace, name) to fake them
# n should be such a 2-tuple
n_namespace = n[0]
n_name = n[1]
n_namespace[n_name] += 1

x = 1
increment((locals(), "x"))
assert x == 2

This is an evil, festering, bletcherous hack, but it is a direct
translation of the use of pass-by-reference in C.

As a bonus, here's a similarly literal python translation of your C
program:

tom

 

[Tom Anderson]

On Mon, 12 Dec 2005 18:51:36 -0600, Larry Bates wrote:

[snippidy-doo-dah]

I had the same thought, but reread the post. He asks "if a given
variable is a character or a number". I figured that even if he is
coming from another language he knows the difference between "a given
variable" and the "contents of a give variable". I guess we will
see.... ;-). This list is so good, he gets BOTH questions answered.

The problem is, Python doesn't have variables (although it is
oh-so-tempting to use the word, I sometimes do myself). It has names in
namespaces, and objects.

In what sense are the names-bound-to-references-to-objects not variables?

Because saying "Python has variables" leads to nonsense like the following:

[snip]

No, python is call by value, and it happens that all values are
pointers.

All values in Python are pointers???
Right.

So when I write:

name = "spam spam spam spam"

the value of the variable "name" is a pointer, and not a string. Riiight.
Right.

Call by value and call by reference have established meanings in
computer science,
Right.

and Python doesn't behave the same as either of them.

Wrong. Python behaves exactly like call by value, just like Smalltalk,
Objective C, LISP, Java, and even C.

Consider the following function:

def modify(L):
"Modify a list and return it."
L.append(None); return L

If I call that function:

mylist = range(10**10) # it is a BIG list
anotherlist = modify(mylist)

if the language is call by value, mylist is DUPLICATED before being
passed to the function.

Wrong. The value of mylist is a pointer to a list, and that's what's
passed to the function. The same analysis applies to the rest of your
example.

The conceptual problem you are having is that you are conflating the
object model of Python the language with the mechanism of the underlying
C implementation, which does simply pass pointers around.

No, i'm not, i'm really not. Thinking in terms of variables, pointers and
objects is a simple, consistent and useful abstract model of computation
in python. If you like, we can use the word 'reference' instead of
'pointer' - i guess a lot of people who came from C (which i didn't) are
hung up on the idea that a pointer is a memory address, rather than just a
conceptual thing which goes from a variable to an object; the trouble is
that then we remind people of 'call by reference', and it all goes to pot.

I think the background thing is the kicker here. I'm guessing you come
from C, where pointers are physical and explicit, you can have a variable
which really does contain an object, etc, and so for you, applying those
terms to python is awkward. I come from java, where all pointers are
abstract (in the sense of being opaque) and implicit, and variables only
ever contain pointers (unless they're primitive - but that's an
implementation detail), so the terminology carries over to python quite
naturally.

I'd love to, but unfortunately I've already hit send on my reply.

Fair enough. Sorry about all this. In future, i'm going to send posts
which i *know* will generate heat but no light straight to /dev/null ...

tom

 

[Tom Anderson]

On Mon, 12 Dec 2005 18:51:36 -0600, Larry Bates wrote:

[snippidy-doo-dah]

I had the same thought, but reread the post. He asks "if a given
variable is a character or a number". I figured that even if he is
coming from another language he knows the difference between "a given
variable" and the "contents of a give variable". I guess we will see....
;-). This list is so good, he gets BOTH questions answered.

The problem is, Python doesn't have variables (although it is
oh-so-tempting to use the word, I sometimes do myself). It has names
in namespaces, and objects.

In what sense are the names-bound-to-references-to-objects not variables?

In a very important sense, one which you should understand in order to
understand the nature of Python.

In C

Stop. How am i going to understand the nature of python by reading about
C? Python is not C. What C does in the privacy of its own compilation unit
is of no concern to us.

if you declare a variable as (for example) a character string of length
24, the compiler will generate code that allocates 24 bytes to this
variable on the stack frame local to the function in which it's
declared. Similarly if you declare a variable as a double-length
floating point number the compiler will emit code that allocates 16
bytes on the local stack-frame.

True but irrelevant.

In Python a name [...] is simply *bound* to a value. The only storage
that is required, therefore, is enough to hold a pointer (to the value
currently bound to the name). Thus assignment (i.e. binding to a name,
as opposed to binding to an element of a data structure) NEVER copes the
object, it simply stores a pointer to the bound object in the part of
the local namespace allocated to that name.

Absolutely true. I'm not saying your terminology is wrong - i'm pointing
out that mine is also right.

Basically, we're both saying:

"""In python, the universe consists of things; in order to manipulate
them, programs use hands, which hold things - the program is expressed as
actions on hands, which direct actions on things at runtime. Although it
appears at first glance that there is a direct correspondence between
hands and things, it is crucial to realise that the relationship is
mediated by a holding - the hand identifies a particular holding, which in
turn identifies a particular thing. So, when we make a function call, and
specify hands as parameters, it is not the hands themselves, *or* the
things, that get passed to the function - it's the holdings. Similarly,
when we make an assignment, we are not assigning a thing - no things are
touched by an assignment - but a holding, so that the hand assigned to
ends up gripping a different thing.

There is in fact another layer of indirection - the programmer refers to
hands using strings, but this is just part of the language used to express
programs textually: the correspondence between these strings and the hands
they refer to is called a manual. The manual which applies at any point in
a program is determined lexically - it is the manual corresponding to the
function enclosing that point, or the global manual, if it is at the top
level.

"""

Where you can substitute either of:

steves_terminology = {
"thing": "value",
"hand": "name",
"hold": "are bound to",
"holding": "binding",
"gripping": "being bound to",
"manual": "namespace"
}

toms_terminology = {
"thing": "object",
"hand": "variable",
"hold": "point to",
"holding": "pointer",
"gripping": "pointing to",
"manual": "scope"
}

Using:

def substitute(text, substitutions):
substituands = substitutions.keys()
# to handle substituands which are prefixes of other substituands:
substituands.sort(lambda a, b: -cmp(len(a), len(b)))
for substituand in substituands:
text = text.replace(substituand, substitutions[substituand])
return text

I'd then point out that my terminology is the one used in all other
programming languages, including languages whose model is the same as
python's, and so we should use it for consistency's sake. I guess the
argument for your terminology is that it's less confusing to C programmers
who don't realise that the * in *foo is now implicit.

You appear very confident of your ignorance ;-)

You appear to be very liberal with your condescension.

Steering rapidly away from further ad hominem attacks ...

Couldn't!

I do apologise, though, for any implication you assertions are based on
ignorance because you do demonstrate quite a sophisticated knowledge of
what goes on under the hood. As long as you can accept that "Python
'variables' are all references" then the rest is indeed semantics.

Right. I think we just agreed.

Of course it will be helpful for newcomers if we can adopt a standard
terminology ...

That's certainly true. We should therefore adopt my terminology as
standard.



tom

 

[Steven D'Aprano]

To restate the first paragraph: Python's calling semantics are a
proper subset of call-by-reference. If the object passed has the same
behavior as it does in a call-by-reference lanuage, then the behavior
of the argument is the same as it is in the call-by-reference
language. You can argue that one of the missing things is crucial to
the definition of call by reference, in which case we disagree about
the meaning of call by reference, and we can stop there. Or you can
argue that there is some object in Python that behaves the same way in
both Python and a call by reference that does not behave the same way
when passed as an argument. I'm still waiting for an example of that.

I'm tired of arguing about this. So I'll just gracefully withdraw from the
fight and point you at two gentlemen who have forgotten more about
computer science than I'm ever likely to learn:

Thanks to Fredrik:

the only thing you need to know is that Python's model is neither "call by
value" nor "call by reference"; the most accurate description is instead
CLU's "call by object" or "call by sharing". Or, if you prefer, "call by
object reference".
[end quote]

http://effbot.org/zone/call-by-object.htm



And from the tutorial by Guido:

The actual parameters (arguments) to a function call are introduced
in the local symbol table of the called function when it is called; thus,
arguments are passed using call by value (where the value is always an
object reference, not the value of the object). [Footnote: Actually, call
by object reference would be a better description, since if a mutable
object is passed, the caller will see any changes the callee makes to it
(items inserted into a list).]
[end quote]

http://docs.python.org/tut/node6.html#tex2html2

 

[Donn Cave]

def modify_in_place(obj):
"""Modify an arbitrary object in place."""
obj = None

x = [1, 2, 3] # mutable object
modify_in_place(x)
assert x is None


Doesn't work either.

To be fair, this isn't because the function is not pass by reference,
but because the assignment operator reassigns the reference rather than
altering the referent, and thus modify_in_place doesn't actually
contain any modifying operations. With a good understanding of what
Python's assignment operator actually does, (I believe) you can view
Python as pass-by-reference without any semantic problems.

What he said!

While I agree (with another post) that there seems to be
a difference in perspective that depends on what language
you were using when you first heard these terms, in the
end it really seems sort of almost disingenuous to argue
that the "value" in question is actually a pointer. (The
pointer is in a practical sense a reference, so what if we
say "pass by reference value?!"

I would like to argue that "value" basically means the
computational effect. In "s = a + b", the value of "b"
is whatever ends up applied to that "+" operator. In
isolation, the value of some object is its computational
potential - the object isn't its value, rather the
implementation of the value. Parameter passing isn't
a computation in this sense, and it doesn't make sense
for it to have its own interpretation of "value".

--

Historically, the way I remember it, there was a time not too
long ago when GvR and his minions sort of dismissed the idea
that you needed to understand the reference/object model from
the outset. I mean, obviously you need to get there eventually
if you're going to be a hard core Python programmer, but they
wanted to see people learning to write programs, without being
encumbered by knowledge of implementation details, and ideas
about the difference between "variable" and "binding" are
certainly about implementation details.

It depends on your ambitions, I suppose, whether that's really
a good idea, since there's no question that some understanding
of the principles involved has to come fairly early. But I think
we really lose out when we try to make it be about the words -
"Python doesn't have variables"/"Does too", "Python passes by
value"/"Does not", etc. When the words really clearly express
the right thing to anyone with a reasonable background, that's
great. But usually, they don't.

Donn Cave, (e-mail address removed)

 

[Fredrik Lundh]

While I agree (with another post) that there seems to be
a difference in perspective that depends on what language
you were using when you first heard these terms, in the
end it really seems sort of almost disingenuous to argue
that the "value" in question is actually a pointer.

The word "value" has a defined meaning in python:

http://docs.python.org/ref/objects.html

(The pointer is in a practical sense a reference, so what
if we say "pass by reference value?!"

"call by object reference" ?

as the CLU folks noted some thirty years ago (my emphasis):

"IN PARTICULAR IT IS NOT CALL BY VALUE because mutations
of arguments performed by the called routine will be visible to
the caller. And IT IS NOT CALL BY REFERENCE because access
is not given to the variables of the caller, but merely to certain
objects."

Arguing that "as long as I can define the word value/reference, it's
call-by-value/reference" is somewhat disingenuous, indeed.

</F>

 

[Tuvas]

I don't know if I can help with this much, I'm still somewhat new to
python, but it is my understanding that "simple" variable, ei, strings,
ints, etc, although they don't have such names, behave like variables,
ei, if you pass them to a function, the function will copy them into a
new spot. However, if you use lists, then it only passes a pointer, or
tuples as well. Ei, I just ran this through the python IDE.
Test

This seems to indicate that the variable is copied, as the value didn't
change. Weither or not Python keeps the variables as pointers
internally, it doesn't really matter. Actually, all languages do such
things, except assembly.

I just ran the test on lists and tuples, it was the same results,
nothing moved.

Other than this, I basically see a fight on terminology, and that's
that.

 

[Mike Meyer]

That's not what call by reference is - call by reference is passing
pointers to *variables* by value.

In which case, Python can't do call-by-reference at all, because it
doesn't have variable.

Of course, I think call-by-reference is passing references to
*objects* by value.

As a bonus, here's a similarly literal python translation of your C
program:

I claim that's not correct, because ref can be used to change i in any
context in C. In your version, ref can only be used to change i if you
have access to the namespace that i lives in. In my version, ref can't
be used to change i at all.

<mike

 

[Mike Meyer]

I would like to argue that "value" basically means the
computational effect. In "s = a + b", the value of "b"
is whatever ends up applied to that "+" operator. In
isolation, the value of some object is its computational
potential - the object isn't its value, rather the
implementation of the value. Parameter passing isn't
a computation in this sense, and it doesn't make sense
for it to have its own interpretation of "value".

Now you're hovering on the edge of call by name.

Historically, the way I remember it, there was a time not too
long ago when GvR and his minions sort of dismissed the idea
that you needed to understand the reference/object model from
the outset. I mean, obviously you need to get there eventually
if you're going to be a hard core Python programmer, but they
wanted to see people learning to write programs, without being
encumbered by knowledge of implementation details, and ideas
about the difference between "variable" and "binding" are
certainly about implementation details.

No, they're not. They're a fundamental part of the semantics of the
language. But you are right - you should be able to learn how to
program in Python without having to learn about those thing. The fact
is, you can do that - if you don't have any preconcieved notions about
what the names are and how they behave. If you have to unlearn things
from another language (like that variables have types, or values that
can be changed), then you'll need the difference explained the first
time the difference is noticable.

<mike

 

[bonono]

I don't know if I can help with this much, I'm still somewhat new to
python, but it is my understanding that "simple" variable, ei, strings,
ints, etc, although they don't have such names, behave like variables,
ei, if you pass them to a function, the function will copy them into a
new spot. However, if you use lists, then it only passes a pointer, or
tuples as well. Ei, I just ran this through the python IDE.

Test

This seems to indicate that the variable is copied, as the value didn't
change. Weither or not Python keeps the variables as pointers
internally, it doesn't really matter. Actually, all languages do such
things, except assembly.

No. They are not copied, at least not at function invokation. The
parameter in the functions scope got rebound(that is the term python
people like to use) to a new value(or object in python term as
everything in python is an object) if you use the "=" operator.

x="test"
y=["test"]
def mod_1(v):
v="blah"

def mod_2(v):
v[0]="blah"

mod_1(x)
print x
mod_1(y)
print y
mod_2(x)
print x
mod_2(y)
print y

You can see that neither x or y changed with mod_1, regardless whether
it is mutable or not. mod_2(x) is an error as it kind of use 'v' as an
object pointer and invoke some method on it(the object) which doesn't
exist for x. mod_2(y) works as expected, because y in this case is sort
of an object which is a container which has the "[]" method.

 

[Mike Meyer]

I don't know if I can help with this much, I'm still somewhat new to
python, but it is my understanding that "simple" variable, ei, strings,
ints, etc, although they don't have such names, behave like variables,
ei, if you pass them to a function, the function will copy them into a
new spot.

No, it doesn't copy them:
.... return id(x) == x_id
....

However, if you use lists, then it only passes a pointer, or
tuples as well. Ei, I just ran this through the python IDE.

It passes a reference to the object in both cases.

Test
This seems to indicate that the variable is copied, as the value didn't
change.

Except that modstring didn't do anything to change the value of x. It
bound the name var in the modstring function to the string "Blah".

Weither or not Python keeps the variables as pointers internally, it
doesn't really matter. Actually, all languages do such things,
except assembly.

No, they don't. In a conventional language - including assembler - a
variable is a *compile-time* object that refers to a specific bit of
memory. Mentioning the name of the variable in your source causes code
to be emitted that loads the value stored in that memory. An
assignment statement causes code to be emitted to that stores a value
in that memory. By the time you get to run time, the variable per se
no longer exists - all references to it have been converted to
references to the memory it specifies. This is grossly
oversimplified, and not true for all languages, including some that
would otherwise be considered conventional.

Other than this, I basically see a fight on terminology, and that's
that.

Could well be.

<mike

 

[Donn Cave]

Quoth Mike Meyer <[email protected]>:
....
|> Historically, the way I remember it, there was a time not too
|> long ago when GvR and his minions sort of dismissed the idea
|> that you needed to understand the reference/object model from
|> the outset. I mean, obviously you need to get there eventually
|> if you're going to be a hard core Python programmer, but they
|> wanted to see people learning to write programs, without being
|> encumbered by knowledge of implementation details, and ideas
|> about the difference between "variable" and "binding" are
|> certainly about implementation details.
|
| No, they're not. They're a fundamental part of the semantics of the
| language. But you are right - you should be able to learn how to
| program in Python without having to learn about those thing. The fact
| is, you can do that - if you don't have any preconcieved notions about
| what the names are and how they behave. If you have to unlearn things
| from another language (like that variables have types, or values that
| can be changed), then you'll need the difference explained the first
| time the difference is noticable.

Yes, it may be easier to learn from a blank slate, though I wouldn't
be too sure. But that is kind of beside the point (are you trying to
answer too many messages per day here?) Either you have to learn it,
or you don't.

Eventually, of course you do have to learn it. At some point you're
confronted with the need to predict what will happen in one of those
perennial examples like a = [], b = a, a.append(c). If you can predict
results accurately every time, then whether you learned it by reading
the documentation or by experimentation, whether you learned it in CS
terminology or understand it in some non-verbal way, in any case you
have learned something about the language itself.

The question is whether basically everyone needs to get there, or we
can expect the masses to use the language _without understanding it_
in this sense, without understanding the language-specific stuff.
I don't know how important that is, I guess it depends on how real
the CP4E world is ever going to be, but I think it's wishful thinking
to expect that to work with Python.

Donn Cave, (e-mail address removed)

 

[Steve Holden]

Quoth Mike Meyer <[email protected]>:
...

The question is whether basically everyone needs to get there, or we
can expect the masses to use the language _without understanding it_
in this sense, without understanding the language-specific stuff.
I don't know how important that is, I guess it depends on how real
the CP4E world is ever going to be, but I think it's wishful thinking
to expect that to work with Python.

Hear, hear. However you describe it Python is what it is, and this
interminable discussion about its similarities with and differences from
various concepts (most lately call by name/call by value) doesn't much
aid understanding for the majority.

The important question is not "what's that Python concept called in
other languages" but "do you understand how Python works".

regards
Steve

 

[Steven D'Aprano]

Hear, hear. However you describe it Python is what it is, and this
interminable discussion about its similarities with and differences from
various concepts (most lately call by name/call by value) doesn't much
aid understanding for the majority.

The important question is not "what's that Python concept called in
other languages" but "do you understand how Python works".

Would you have a problem with me describing Python as an untyped
high-level assembly-language, and then working around the lack of JMP
using try...exempt?

Of course, I understand that it is no skin off your nose whether I write
bad code or not, but you might get mighty frustrated with my constant
questions on the news group "How do I write this piece of assembly code in
Python?".