file_ref = open(string_ref)

[Steve Holden]

"Greg Weeks" <weeks at vitus.scs.agilent.com> wrote ...
> Is this code
>
> C1: file_ref = open(string_ref)
>
> better than this?:
>
> C2: file = open(string)
>
Well, let's first agree that all such matters are subjective and that beauty
is in the eye of the beholder, so there's room for disagreement. As long as
the disagreement is honest and respectful I'm happy to play ...

> C1 is more accurate, given the view that data in Python are references to
> objects.  According to this view, the left-hand variable names a reference
> to a file object.
>
"Data"? Really here we mean things like names, dictionary values and list
elements, right?

Because *all* names are references to objects, it seems reasonable to prefer
C2 to C1, in my (pragmatist's) opinion.

> I can't believe that C1 is superior to C2 or that the millions of lines of
> Python, Lisp, and Java code similar to C2 are in any way wrong.  So, in my
> opinion, our view of data is wrong.  To align our view of data to our
code,
> we need to replace the view
>
> V1: Objects are regions of memory.
>
> with:
>
> V2: Objects are addresses (of regions of memory).
>
Aaarrrggghhh!  No!!!!!!!!! Objects *are* regions of memory. Binding (e.g.
assignment, function declaration, et al) doesn't store an object, it stores
*a reference* to an object.

> If we adopt V2, then C2 (and all the code like it) is correct.  file is an
> object, string is an object, and even open is an object.  If we prefer V1,
> on the other hand, then we must consider C1 more correct.
>
Not the view I would take of correctness.

> The problem with V1 is not simply a mismatch between our concepts and our
> Lisp, Java, and Python code.  The sad fact is that the majority of C code
> that I've seen resembles C1.  This code is just as ugly and unnecessary in
> C as it would be in Python.
>
The difference is that in C, variables hold values. Assignment actually
stores an expression's value in a location. Some of the expressions are
explicitly cast as references, in which case the variable has to be
acknowledged as holding a reference.

That's (mostly) because C does not necessarily perform Python's implicit
dereferencing. In Python, when we use a name (said Humpty...) we accept
implicitly that we are referring to an object. In C, an experession might
evaluate to a type, or to a reference to a type (and, since references are
also type, references to references to ...).

There's no way in Python to store anything *but* references to objects, and
indeed the Python garbage collector actually collects things only when their
reference count reduces to zero.

> So, every now and then, I raise the "Objects are addresses" flag.
>
Don't. They aren't ;-). They are (dare I say it) *referred to* by their
addresses.

>
> Greg
>
>
> PS: Note that I don't proclaim "Objects are references".  The term
> "reference" is ambiguous and heavy with misleading connotation.
>
What else is an address but a reference? Objects aren't references, but we
use references to locate them.

> PS: In "Objects are addresses", "Objects" does not include the numerical
> values of Java or the numerical or structure values of C.  If this is a
> problem, then V1 has the same problem.
>
You have to say this because of a failure to distinguish beteen values and
references. In Java you have to discriminate carefully between, for example,
integers (which aren't objects) and Integers (which are). In Python, all
values are objects, so it doesn't matter as much.

> PS: What about C++.  Ucch, the worst.  C++ extravagently supports V1 by
> allowing "initialization by reference", whereby a variable is initialized
> to the same region of memory as another variable.  The result is
> considerably more complicated than Python, Lisp, and Java.  And it doesn't
> quite hang together, since there is no assignment by reference.

I'll leave this to Alex Martelli, who knows C++ fat better than I.

regards
 Steve
--

home: http://www.holdenweb.com/
Python Web Programming:
http://pydish.holdenweb.com/pwp/