In article mailman.952.1235850376.11746.python-l...@python.org,
rdmur...@bitdance.com wrote:
I think this is the key point. I am an experienced Python programmer,
and I had to think long and hard about what you were saying, Mark, in
order to understand how it applied to Python. I think this
Aahz wrote:
In article mailman.952.1235850376.11746.python-l...@python.org,
rdmur...@bitdance.com wrote:
I think this is the key point. I am an experienced Python programmer,
and I had to think long and hard about what you were saying, Mark, in
order to understand how it applied to Python. I
Ethan Furman et...@stoneleaf.us writes:
Mark Wooding wrote:
Here's what I think is the defining property of pass-by-value [...]:
The callee's parameters are /new variables/, initialized /as if by
assignment/ from the values of caller's argument expressions.
My soundbite definition for
Mark Wooding m...@distorted.org.uk wrote:
Ethan Furman et...@stoneleaf.us writes:
Mark Wooding wrote:
Here's what I think is the defining property of pass-by-value [...]:
The callee's parameters are /new variables/, initialized /as if by
assignment/ from the values of caller's
Ethan Furman et...@stoneleaf.us wrote:
Specifically, how is a new name (pbr) different, in Python, from a new
name initialized as if by assignment (pbv)? It seems to me than you end
up with the same thing in either case (in Python, at least), making the
distinction non-existent.
def
Mark Wooding wrote:
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
On the one hand, some people (me and possibly rurpy) consider this is
pass-by-foo to be a statement about behaviour directly visible to the
programmer. We have a set of behavioral traits in mind, and if a
On Fri, 27 Feb 2009 23:55:43 -, Ethan Furman et...@stoneleaf.us
wrote:
I'm not Mark, but you did post to the whole group!
[snippety snip]
Specifically, how is a new name (pbr) different, in Python, from a new
name initialized as if by assignment (pbv)? It seems to me than you end
up
On Jan 5, 9:03 am, Derek Martin c...@pizzashack.org wrote:
On Sat, Jan 03, 2009 at 10:15:51AM +, Marc 'BlackJack' Rintsch wrote:
On Fri, 02 Jan 2009 04:39:15 -0600, Derek Martin wrote:
On Tue, Dec 30, 2008 at 02:21:29PM +, John O'Hagan wrote:
What the Python community often
On Tue, 13 Jan 2009 23:06:58 +, Mark Wooding wrote:
I'm going to move away from the formal semantics stuff and try a
different tack. Here's what I think is the defining property of
pass-by-value (distilled from the formal approach I described earlier,
but shorn of the symbolism):
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
Ah! (say I) but assignment in C and Pascal looks different from the way
it looks in C
I'm sorry, that confuses me. Assignment in C looks different from the way
it looks in C? I guess the second C should be Python.
Yes, you're
Aaron Brady castiro...@gmail.com wrote:
On Jan 13, 5:06 pm, Mark Wooding m...@distorted.org.uk wrote:
snip
I'm going to move away from the formal semantics stuff and try a
different tack. Here's what I think is the defining property of
pass-by-value (distilled from the formal approach I
On Jan 14, 3:51 am, Mark Wooding m...@distorted.org.uk wrote:
Aaron Brady castiro...@gmail.com wrote:
On Jan 13, 5:06 pm, Mark Wooding m...@distorted.org.uk wrote:
snip
I'm going to move away from the formal semantics stuff and try a
different tack. Here's what I think is the defining
On Sat, 10 Jan 2009 15:46:35 +, Mark Wooding wrote:
[Another tome. I hope this contains sufficient new material to continue
to be of interest to other readers.]
I found it interesting. I don't know about others. However, at 756 lines
(including quoting) it was nearly double the size of
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
I found it interesting.
Well, that's something, at any rate.
I think this conversation is reaching it's natural end. Frustration
levels are rising.
I think you may be right. That said...
So I'm going to take a different tack
On Jan 13, 5:06 pm, Mark Wooding m...@distorted.org.uk wrote:
snip
I'm going to move away from the formal semantics stuff and try a
different tack. Here's what I think is the defining property of
pass-by-value (distilled from the formal approach I described earlier,
but shorn of the
ru...@yahoo.com ru...@yahoo.com wrote:
Mark Wooding wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
What is the observable difference between converting an
array to a reference (pointer) to that array and passing
the reference by value, and passing the array by reference?
For one:
On Jan 10, 1:49 pm, Joe Strout j...@strout.net wrote:
Aaron Brady wrote:
Aaron Brady wrote:
Possible compromise. You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name. The old
name doesn't go in. /compromise
That's correct. The
On Sun, 11 Jan 2009 03:25:24 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
I don't believe it is a red-herring. As I understand it, Mark and Joe
insist that C is pass-by-value *even in the case of arrays*, despite
the semantics of array passing being
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
If it walks like pass-by-reference, and smells like pass-by-reference,
and swims like pass-by-reference, is it still your contention that it is
pass-by-value?
Of course the C example is pass by value. It's just that the value
On Jan 11, 8:32 am, Paul Rubin http://phr...@nospam.invalid wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
If it walks like pass-by-reference, and smells like pass-by-reference,
and swims like pass-by-reference, is it still your contention that it is
pass-by-value?
Of
On Sun, 11 Jan 2009 06:32:31 -0800, Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
If it walks like pass-by-reference, and smells like pass-by-reference,
and swims like pass-by-reference, is it still your contention that it
is pass-by-value?
Of course the C
Aaron Brady castiro...@gmail.com wrote:
True or not, it requires the reader to know what references are. And,
since your definition conflicts with the C++ definition, it's not
clear that the requirement is good.
I blame C++ for coopting a perfectly good word with a established
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
I guess this is where you explain again that arrays in C are bizarre,
and that while int arr[2] inside a function body means declare an
array of two ints and call it 'arr', the exact same declaration in a
function parameter list
Mark Wooding wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
Mark Wooding wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
...
For another:
static void bar(char v[]) { char ch = 0; v = ch; }
/* type error if arrays truly passed by reference */
v can be used as an array reference, e.g.
ru...@yahoo.com ru...@yahoo.com wrote:
But if you'll note, I said if ... referring to a couple of
hypothetical C-like languages, so your chapter-and-verse quote from
the standard, while interesting and appreciated, was basically
irrelevant.
Ah, what you actually said was still quoted above
On Fri, 09 Jan 2009 20:23:11 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
I'm pretty sure that no other pure-Python coder has manipulated
references either. They've manipulated objects.
No: not directly. The Python program deals solely with
On Jan 9, 9:30 am, Joe Strout j...@strout.net wrote:
Aaron Brady wrote:
Possible compromise. You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name. The old
name doesn't go in. /compromise
That's correct. The reference itself is passed
[Another tome. I hope this contains sufficient new material to continue
to be of interest to other readers.]
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
On Fri, 09 Jan 2009 20:23:11 +, Mark Wooding wrote:
No: not directly. The Python program deals solely with references;
ru...@yahoo.com ru...@yahoo.com wrote:
Agreed. I think the docs, especially those that develop
the conceptual model of how Python work at runtime, could
use some major attention.
If we can achieve consensus in this (still remarkably civil) discussion,
we might be able to amend the docs.
I
Aaron Brady wrote:
Lastly, I don't see any reason why we couldn't make both explanations
available. 'For those coming from Java/etc; for those coming from
C++/etc.' They would both get read.
That's what I was just thinking .. there are lots of others, too: for those
coming from
On Jan 9, 6:47 am, Mark Wooding m...@distorted.org.uk wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
As a side comment (because it always bugs me when I read this, even
though I read it in very authoritative sources), ISTM that C passes
everything by value except arrays; they are passed by
ru...@yahoo.com ru...@yahoo.com wrote:
What is the observable difference between converting an
array to a reference (pointer) to that array and passing
the reference by value, and passing the array by reference?
For one:
#include stdio.h
static size_t foo(char v[]) { return sizeof v; }
int
ru...@yahoo.com wrote:
What is the observable difference between converting an
array to a reference (pointer) to that array and passing
the reference by value, and passing the array by reference?
The difference is whether an assignment to the formal parameter (within
the function) affects
Aaron Brady wrote:
Aaron Brady wrote:
Possible compromise. You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name. The old
name doesn't go in. /compromise
That's correct. The reference itself is passed in, not the variable (or
expression)
On Sat, 10 Jan 2009 12:52:47 -0700, Joe Strout wrote:
What is the observable difference between converting an array to a
reference (pointer) to that array and passing the reference by value,
and passing the array by reference?
The difference is whether an assignment to the formal parameter
On Sat, 10 Jan 2009 18:44:37 -, ru...@yahoo.com wrote:
What is the observable difference between converting an
array to a reference (pointer) to that array and passing
the reference by value, and passing the array by reference?
This is a red herring, though. From either viewpoint, C
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
There are actually three fundamental characteristics of pass-by-reference:
* passing a value by reference does not lead to the value being copied,
in contrast with pass-by-value where it does;
* modifications to the value passed
On Sun, 11 Jan 2009 01:22:48 +, Rhodri James wrote:
On Sat, 10 Jan 2009 18:44:37 -, ru...@yahoo.com wrote:
What is the observable difference between converting an array to a
reference (pointer) to that array and passing the reference by value,
and passing the array by reference?
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
I don't believe it is a red-herring. As I understand it, Mark and Joe
insist that C is pass-by-value *even in the case of arrays*, despite the
semantics of array passing being identical to the semantics of pass-by-
reference in
Mark Wooding wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
What is the observable difference between converting an
array to a reference (pointer) to that array and passing
the reference by value, and passing the array by reference?
For one:
#include stdio.h
static size_t foo(char v[]) {
On Thu, 08 Jan 2009 18:33:50 +, Mark Wooding wrote:
[Steven's message hasn't reached my server, so I'll reply to it here.
Sorry if this is confusing.]
Aaron Brady castiro...@gmail.com wrote:
On Jan 8, 1:45 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
On Wed, 07
On Jan 9, 4:01 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Thu, 08 Jan 2009 18:33:50 +, Mark Wooding wrote:
[Steven's message hasn't reached my server, so I'll reply to it here.
Sorry if this is confusing.]
Aaron Brady castiro...@gmail.com wrote:
On Jan 8,
ru...@yahoo.com wrote:
a = array (1,2,3)
b = a
a[1] = 4
print b
C, C++, VBA, Fortran, Perl: 1, 2, 3
Python: 1, 4, 3
You are mistaken
I don't think so.
See http://groups.google.com/group/comp.lang.python/msg/f99d5a0d8f869b96
The code I quoted there was tested.
In the C/C++ case,
Aaron Brady wrote:
Possible compromise. You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name. The old
name doesn't go in. /compromise
That's correct. The reference itself is passed in, not the variable (or
expression) that held or
ru...@yahoo.com ru...@yahoo.com wrote:
As a side comment (because it always bugs me when I read this, even
though I read it in very authoritative sources), ISTM that C passes
everything by value except arrays; they are passed by reference (by
passing a pointer to the array by value.)
Joe Strout wrote:
Aaron Brady wrote:
Possible compromise. You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name. The old
name doesn't go in. /compromise
That's correct. The reference itself is passed in, not the variable (or
expression)
On Fri, 09 Jan 2009 08:30:46 -0700, Joe Strout wrote:
That's correct. The reference itself is passed in, not the variable (or
expression) that held or generated the reference in the calling code.
This is no different from, in C, passing an integer:
void foo(int bar) {
bar = 42;
}
Joe Strout wrote:
ru...@yahoo.com wrote:
a = array (1,2,3)
b = a
a[1] = 4
print b
C, C++, VBA, Fortran, Perl: 1, 2, 3
Python: 1, 4, 3
You are mistaken
I don't think so.
See http://groups.google.com/group/comp.lang.python/msg/f99d5a0d8f869b96
The code I quoted there was
ru...@yahoo.com wrote:
I never claimed that you *couldn't* have copy semantics in C; you can do
almost anything you want in C (or C++). But the *normal* usage of an
array is via a pointer, in which case the semantics are exactly the same
as in Python, Java, REALbasic, .NET, etc.
Arrays are
[Sigh. I must apologize for the length of this article. I can't, alas,
see a satisfactory way of trimming it. The doubly-quoted stuff later on
was by me.]
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
I'm pretty sure that no other pure-Python coder has manipulated
references
Aaron Brady castiro...@gmail.com wrote:
Possible compromise. You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name. The old
name doesn't go in. /compromise
Huh? That doesn't explain circular data structures at all, unless your
idea of `name'
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
Python doesn't do the same thing as C. It actually passes the same value
to the function, without copying it.
Why oh why do you keep insisting that Python is no different from C?
I'm beginning to think that you're not bothing to
ru...@yahoo.com ru...@yahoo.com wrote:
If one accepts that there are a lot of people who post in here that
clearly are surprised by Python's assignment semantics,
But one should not accept that. One might accept that there are many
who post who claim that they are surprised by Python's
Mark Wooding wrote:
As an aside, I don't notice anywhere near as much confusion in Lisp and
Scheme groups, which might be surprising since Lisp and Scheme have
precisely the same data model, argument passing convention, and
assignment semantics, as Python has.
Nor is there anywhere near as
Joe Strout wrote:
ru...@yahoo.com wrote:
I never claimed that you *couldn't* have copy semantics in C; you can do
almost anything you want in C (or C++). But the *normal* usage of an
array is via a pointer, in which case the semantics are exactly the same
as in Python, Java, REALbasic,
On Fri, Jan 9, 2009 at 7:11 PM, Joe Strout j...@strout.net wrote:
Mark Wooding wrote:
.NET isn't a language at all:
rather, it's a virtual machine, runtime system, class library and family
of languages each of which may have idiosyncratic semantics.
But they don't, AFAIK -- they all
On Fri, 09 Jan 2009 21:03:39 +, Mark Wooding wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
Python doesn't do the same thing as C. It actually passes the same
value to the function, without copying it.
Why oh why do you keep insisting that Python is no different
On 2009-01-10, Joe Strout j...@strout.net wrote:
Mark Wooding wrote:
As an aside, I don't notice anywhere near as much confusion in Lisp and
Scheme groups, which might be surprising since Lisp and Scheme have
precisely the same data model, argument passing convention, and
assignment
On Sat, 10 Jan 2009 00:21:27 -, ru...@yahoo.com wrote:
Joe Strout wrote:
ru...@yahoo.com wrote:
[snip]
Pointers are passed and assigned by value, just as
other types (disputedly except arrays) are.
One can then use that pointer to manually effect
Joe Strout j...@strout.net wrote:
No, actually, that was me. rurpy's list was something like C, FORTRAN,
Perl, and VBA.
My mistake -- I failed to read the quoting properly. Apologies to all.
We still dealt with C.
Fortran (to give it its modern spelling) has a similar data model to C,
but
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
Er, perhaps you missed that I was replying to Joe Strout.
Yes, evidently. My apologies for the mix up!
-- [mdw], who obviously should put the keyboard down now.
--
http://mail.python.org/mailman/listinfo/python-list
Mark Wooding wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
If one accepts that there are a lot of people who post in here that
clearly are surprised by Python's assignment semantics,
But one should not accept that. One might accept that there are many
who post who claim that they are
Rhodri James wrote:
On Sat, 10 Jan 2009 00:21:27 -, ru...@yahoo.com wrote:
IIRC, Someone posted here that his experience was
that 12-year old kids (presumably without programming
experience) had no problem with Python and references
when described as names given to an object. (From
On Wed, 07 Jan 2009 03:45:00 -0800, sturlamolden wrote:
On Jan 7, 2:02 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
In Python code, there are no references and no dereferencing.
The why does CPython keep track of reference counts?
Two different levels of explanation.
On Jan 8, 1:45 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote:
snip
The `they're just objects' model is very simple, but gets tied up in
knots explaining things. The `it's all references' model is only a
little more
ru...@yahoo.com ru...@yahoo.com wrote:
I thought you were objecting to Python's use of the term binding
when you wrote:
[snip]
in response to someone talking about ...all those who use the term
\name binding\ instead of variable assignment
Oh, that. Well, the terms are `binding' and
Aaron Brady wrote:
On Jan 8, 1:45 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote:
snip
The `they're just objects' model is very simple, but gets tied up in
knots explaining things. The `it's all references' model is
Absolutely.
Trivially and at a high level,
teaching python to kids who are learning programming as introductory
material
teaching python to motivated college graduate students
teaching python to adult non-professional programmers with a need to learn
python (like for instance, frustrated
[Steven's message hasn't reached my server, so I'll reply to it here.
Sorry if this is confusing.]
Aaron Brady castiro...@gmail.com wrote:
On Jan 8, 1:45 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote:
The `they're
Erik Max Francis m...@alcyone.com wrote:
Terry Reedy wrote:
a='par'+'rot'
b='parrot'
a is b
True
One exactly doesn't really say much. It's implementation dependent, and
depends on the length of the string:
a = 'this is a much longer ' + 'parrot'
b = 'this is a much
Mark Wooding wrote:
The `they're just objects' model is very simple, but gets tied up in
knots explaining things. The `it's all references' model is only a
little more complicated, but explains everything.
But it *over* explains, because it implies things that everybody knows
about references
Mark Wooding wrote:
...
Python doesn't need another name for assignment,
OK.
because actually its
idea of assignment is the same as anyone else's. The difference is in
the way it deals with objects. See argument elsewhere.
the same as anyone else's only if [Python's] idea
of assignment
Mark Wooding wrote:
...
I agree with the comment about Pascal, but C is actually pretty similar
to Python here. C only does pass-by-value.
As a side comment (because it always bugs me when
I read this, even though I read it in very authoritative
sources), ISTM that C passes everything by value
ru...@yahoo.com wrote:
the same as anyone else's only if [Python's] idea
of assignment does not include producing the same
results.
a = array (1,2,3)
b = a
a[1] = 4
print b
C, C++, VBA, Fortran, Perl: 1, 2, 3
Python: 1, 4, 3
You are mistaken (except perhaps in the Fortran case,
Joe Strout wrote:
ru...@yahoo.com wrote:
the same as anyone else's only if [Python's] idea
of assignment does not include producing the same
results.
a = array (1,2,3)
b = a
a[1] = 4
print b
C, C++, VBA, Fortran, Perl: 1, 2, 3
Python: 1, 4, 3
You are mistaken
I don't
Mark Wooding m.@distorted.org.uk wrote:
A better analogy. The objects are scattered across the floor. No
object is contained in another. However, we have a plentiful supply of
bits of string, each of which is tied to a Teflon-covered paperweight at
one end and has a blob of Blu-Tack on
On Wed, 07 Jan 2009 03:49:02 +, Mark Wooding wrote:
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
The only tricky thing is that items 1, 2 and 3 can be inside two
different boxes at the same time. There's no obvious real world analogy
to that without the boxes being
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
Only in the sense that the behaviour of *real world* objects don't
entirely match the behaviour of Python objects. If you just accept
that Python objects can be in two places at once, an unintuitive
concept I accept but hardly
On Jan 7, 2:02 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
In Python code, there are no references and no dereferencing.
The why does CPython keep track of reference counts?
You can't, because Python doesn't have references. In a language with
references, that's easy.
On Wed, 07 Jan 2009 03:45:00 -0800, sturlamolden wrote:
On Jan 7, 2:02 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
In Python code, there are no references and no dereferencing.
The why does CPython keep track of reference counts?
Show me the *Python* code that does
Wait a sec...
I think I get this...
In essence, the implication of immutability for Python is that there is only
one parrot, one spam,in fact one anything. (This seems like it must hold
for data primitives - does it hold for complex objects as well? It seems it
must...) In addition there is only
Dan Esch wrote:
Wait a sec...
I think I get this...
In essence, the implication of immutability for Python is that there is
only one parrot, one spam,in fact one anything. (This seems like it
must hold for data primitives - does it hold for complex objects as
well? It seems it must...)
Okay, thanks...
Still trying to wrap my fragile little VBA-corrupted brain around names,
namespaces, and objects. Progress is being made.
For me, the naive idea of variable == label for bin has been hard to
get past simply because someone in the the back of my head is screaming,
Wait, if the
On Jan 6, 9:20 pm, Mark Wooding m...@distorted.org.uk wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
Is not the proper term aliasing? Perhaps Python variables should
be called alises.
No. The proper term is most definitely `binding': see SICP, for
example. (Wikipedia has a link to the
Dan Esch wrote:
In essence, the implication of immutability for Python is that there is
only one parrot, one spam,in fact one anything. (This seems like it
must hold for data primitives - does it hold for complex objects as
well? It seems it must...) In addition there is only one 1, and one 2
Joe Strout wrote:
That's not necessarily true. If you have
a = par + rot
b = parrot
then, most likely (though it depends on how clever the compiler
optimizations are), there are two different string objects containing
the data parrot.
a='par'+'rot'
b='parrot'
a is b
True
--
On Jan 5, 12:21 pm, Derek Martin c...@pizzashack.org wrote:
...
I understand why the assignment model works the way it does, and it's
quite sensible, *when you understand it*. However, I do also think
that to someone who has not encountered such a model before, and who
has not had it
Terry Reedy wrote:
Joe Strout wrote:
That's not necessarily true. If you have
a = par + rot
b = parrot
then, most likely (though it depends on how clever the compiler
optimizations are), there are two different string objects containing
the data parrot.
a='par'+'rot'
b='parrot'
On Wed, Jan 7, 2009 at 7:22 PM, Terry Reedy tjre...@udel.edu wrote:
Joe Strout wrote:
That's not necessarily true. If you have
a = par + rot
b = parrot
then, most likely (though it depends on how clever the compiler
optimizations are), there are two different string objects
On Thu, 08 Jan 2009 00:45:06 -, ru...@yahoo.com wrote:
When I started using Python I had no problem with Python's
assignment semantics because I had been using references in
Perl for years. I did not have a very hard time with Perl's
references, after I recognized their similarities to C's
Rhodri James wrote:
On Thu, 08 Jan 2009 00:45:06 -, ru...@yahoo.com wrote:
When I started using Python I had no problem with Python's
assignment semantics because I had been using references in
Perl for years. I did not have a very hard time with Perl's
references, after I recognized
On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote:
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
Only in the sense that the behaviour of *real world* objects don't
entirely match the behaviour of Python objects. If you just accept that
Python objects can be in two places
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
By all means, if Derek doesn't like the assignment model used by Python
(and Java, Ruby, C#, Perl, RealBasic, VisualBasic, Lua, and many other
languages going back to at least CLU in the mid 1970s)
It goes back to Lisp in the
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
(3) Those who come from an entirely different programming model, say,
Forth or Haskell. For them, Python's assignment model is going to be the
least of their worries.
Actually, Haskell's assignment model (you have to grubbing about
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote:
I don't think so. Variables in algebra are quite different from variables
in programming languages. Contrast the statement:
x = x+1
as a programming expression and an algebraic equation. As a programming
expression, it means
Derek Martin c...@pizzashack.org wrote:
I think I have though, not that it matters, since that was never
really my point. Python's assignment model requires more explanation
than the traditional one, simply to state what it does. That alone is
evidence (but not proof).
Hmm. Actually, it's
Mark Wooding wrote:
Derek Martin c...@pizzashack.org wrote:
I think I have though, not that it matters, since that was never
really my point. Python's assignment model requires more explanation
than the traditional one, simply to state what it does. That alone is
evidence (but not proof).
On Jan 2, 5:43 pm, Steve Holden st...@holdenweb.com wrote:
Derek Martin wrote:
On Tue, Dec 30, 2008 at 02:21:29PM +, John O'Hagan wrote:
[...]
What the Python community often overlooks, when this discussion again
rears its ugly head (as it seems to every other hour or so), is that
On Jan 2, 11:39 am, Derek Martin c...@pizzashack.org wrote:
What the Python community often overlooks, when this discussion again
rears its ugly head (as it seems to every other hour or so), is that
its assignment model is BIZARRE, as in it's conceptually different
from virtually all other
On Jan 6, 8:03 am, Mark Wooding m...@distorted.org.uk wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
snip
It seems that you don't include in the Python community all those who
use the term name binding instead of variable assignment
specifically because it gives new
1 - 100 of 166 matches
Mail list logo
