[Edu-sig] Sticky-note Analogy

[kirby urner]

On Tue, May 13, 2008 at 2:10 PM, Christopher Thoday
<chris at cthoday.uklinux.net> wrote:
>
>  Would it not be better to describe the differences between C and Python
> variables directly rather than using an analogy?
>

Sometimes pure analogies are better though because if you talk
too literally in terms of computer memory then what you're giving
are implementation details, not necessarily useful heuristics.

It so happens that C is very much about computer memory (even
conceptually), which tends to erode this distinction.  That's why it's
considered a low level language, Python a high one -- not a moral
distinction about better vs. worse, but a technical one about how
close to the metal (conceptually).

>  In C, a variable is the address of a storage location that contains its
> value. If that value is itself an address then the variable is described as
> a pointer.
>
>  In Python, a variable is a reference to an object that has a type as well
> as a value.

In C, the conceptual model includes this "wall of memory bricks" (each
brick with an address) that contain data but no awareness of type.

Raw content is all crammed into these bricks as tightly as feasible (holes
unavoidable sometimes).  You can decode the same data as a different
type simply by reading it with a different type of pointer.

When you advance a pointer to a struct, C skips by the right number of
bytes thanks to the type awareness originally provided by struct
declarations in source code.

>
>  The statement:
>
>    a= b = c;
>
>  results in three separate values in C but only one in Python.  The effect
> is the same in both languages provided that c refers to a constant. However,
> if c is a mutable object, such as a list, then changing the value of one
> variable changes them all. Anyone coming to Python from C may be confused by
> this as it is not clearly described in any of the books on Python that I
> have read.

Python names have a many-to-one relationship to objects.  You can
go x = y = z = 8; del y; and still have x and z in the namespace, both
referencing the 8 object.

The fact of 8 being immutable shouldn't be allowed to confuse the
picture of a many-to-one relationship.

Going y = 10 is merely rebinding the name y to a different object,
leaving the others alone.

C has this same many-to-one capability with respect to its pointers,
which may be passed by assignment.

http://cslibrary.stanford.edu/106/

>  When passing an argument to a function, C uses pass-by-value whereas Python
> uses what is in effect pass-by-reference. In order to obtain
> pass-by-reference in C the value must be a pointer. Inside the function the
> pointer must be dereferenced by prefixing it with an asterisk to obtain the
> value.
>
>  Eur Ing Christopher Thoday
>  Software Engineer

I'd say that in C, type awareness stays with the variables, as the
data bricks know nothing of type, yet the pointers know what they
point to, how many bytes to advance, or to read when dereferenced.

Struct variables also support -> notation, prototypical of dot notation
(historically, structs and struct notation were the basis of the first
object oriented implementation of C, i.e. C++).

You could tell C programmers "everything is a struct in Python,
except structs may include functions, access their own data etc."
Then say "all variables are pointers to structs".  But you have
to be careful to explain this is just an analogy, not a literal
fact about implementation (obviously).

In Python, type awareness resides with the objects, with
namespaces being dictionaries of name:object pairs (many-to
one).

There's no concept of "dumb data" (even 8 is an object) or
addressing bricks per se, although we can get integer ids
for our objects as in id(y).

You can't do much with that id though, except figure out if
another name has the same one (the purpose of "is").

Names are little more than Unicode string literals with top-level
significance, each paired with an object in a dictionary (the
namespace).

So in C, intelligence about type remains with the variables
(we might say), whereas in Python it remains with the objects,
which are quite introspective.

Kirby