Qualified appology (was Re: anything like C++ references?)

[Martin v. Löwis]

Stephen Horne <intentionally at blank.co.uk> writes:

> I've said my piece on meanings derived from computer science (and in
> turn from mathematics, as it happens - variables as placeholders for
> values predate electronic computers by quite some time.

And so does mine: Variables are *not* containers of values, in
traditional mathematics. They are bound to values instead.

> Even so, you can think of immutable objects as achieving 'expected'
> assignment semantics simply because they are immutable. That does not
> apply to mutable objects. So you can claim that Python behaviour is
> consistent within itself, but only by claiming that it is consistently
> different from this 'expected' behaviour.

I am firmly convinced that your understanding of assignment is in
complete contradiction with traditional computer science, and the
notion of variables from a time that predates electronic computers.

So your expectation is wrong. Assignment does not mean that something
is copied, it means that something is *bound*.

> That's not the same thing as saying they are doing 'the right thing'
> or that the computer science definitions don't exist

You haven't given proof that these definitions do exist in "computer
science", and that the definitions match your understanding. To do so,
you would have to refer to some widely-used literature where a precise
definition of "variable" and "assignment" is given. 

So far, you didn't show such proof - and anybody claiming that
literature fails to give proper definition, is inconsistent across
authors, or typically gives definitions that are different from your
understanding might be just as right as you might be.

> All variables are implemented as references, but that is not the same
> as saying that all values are references. 

That's true. Values are not references, in Python. Values are values.

> As Guidos own words reveal (I already posted the link twice) the
> purpose of using immutables tuples is performance optimisation to
> save copying while still defending against against accidental
> mutation (ie it provides the computer theory standard assignment
> semantics efficiently).
>
> The same rationale should equally apply to all types, including the
> mutable types.

What is "the same" here: That mutable values should save copying when
being assigned? This is the case. That mutable values should be
protected against accidental mutation? That would be pointless - they
are mutable on purpose.

> I shouldn't need to force copying of class instances in the
> container for the exact same reason that Guido highlights for
> tuples.

It is a good thing that you need to invoke explicit code to perform
copying of objects. For objects, in general, you have the choice of
shallow or deep copies. Either may be meaningful, depending on the
context, and the language should not guess. Also, some objects (files,
windows) don't have a meaningful copy semantics in the first place.

Assignment has nothing to do with copying.

> Having copy-on-write for all objects (obviously the actual copying
> never happening for immutables) would be both fully self-consistent
> and consistent with the computer science definitions.

I can only repeat myself here: Assignment has nothing to do with
copying.

Regards,
Martin