Finding the instance reference of an object

[Terry Reedy]

Aaron Brady wrote:

> and you can't have languages without implementations.

This is either a claim that languages are their own implementations, or 
an admission that human brains are the implementation of all languages 
thought of by human brains, coupled with a claim that there cannot be 
languages not thought of by humans, or just wrong in terms of the common 
meaning of algorithmic implementation of an interpreter.  There are many 
algorithm languages without such implementations.  They were once called 
'pseudocode'. (I don't know if that term is still used much.)  Hence my 
oxymoronic definition, a decade ago, of Python as 'executable pseudocode'.

 > Though, you do not need to understand the
> implementation to understand the language.

Languages are typically defined before there is any implementation. 
They are implemented if they are understood as being worth the effort.

> I haven't thought it through completely, but now that Joe mentions it,
> it appears Python behaves the same as C++,

Python and C/C++ have completely different object and data models.  You 
and Joe are completely welcome to understand/model Python in terms of 
the C implementation, if you wish, but it not necessary and, I believe, 
a disservice to push such a model on beginners as *the* way to model Python.

> if variables can't be
> anything but pointers, parameters are all c-b-v, and you can't
> dereference the l-h-s of an assignment ( '*a= SomeClass()' ).

I don't understand this.

> When you're explaining Python to a beginner, you have to introduce a
> new term either way.  You'll either have to explain pointers, which

Python has no concept of pointers.

> there are chapters and chapters on in introductory textbooks; or,
> you'll have to explain a new calling mechanism, and give it a name.

I disagree.  In everyday life, we have multiple names for objects and 
classes of objects.  We nearly always define procedures in terms of 
generic object classes (common nouns) rather than particular objects. 
We apply procedures by binding generic names to particular objects, by 
associating them with objects, by filling in the named blanks.  This is 
what Python does.  Except for the particular formalized syntax, there is 
nothing new, not even the idea of a specialized procedure language.

def make_cookies(flour, oil, sugar, egg, bowl, spoon, cookie_pan, oven):
     "flour, oil, and sugar are containers with respectively at least 2 
cups, 1 tablespoon, and 1/4 cup of the indicated material"
     mix(bowl, spoon, measure(flour, '2 cups'), measure(sugar, '1/4 cup'))
     <etc>

OK, there is one important difference.  The concrete referents for the 
parameters are non-physical information objects rather than physical 
objects.

>> I would say that an oject is passed, not a reference.

> I agree, and anything else would be overcomplicated.

To me, 'pass' implies movement, but in Python, objects don't really have 
a position and hence cannot move.  So I would say that an object is 
associated (with a parameter).  'Associating' is a primitive operation 
for Python interpreters.  If and when all parameters get associated with 
something, the function code is activated.  Then the return object gets 
associated with the call expression in the computation graph.

Terry Jan Reedy