An object is an instance (or not)?

[Rustom Mody]

On Wednesday, January 28, 2015 at 1:42:47 AM UTC+5:30, Mario Figueiredo wrote:
> This is a follow up from a previous discussion in which it is argued 
> that the following code produces the correct error message terminology, 
> considering that in Python an object is also an instance.
> 
>     >>> class Sub:
>     >>>     pass
>     
>     >>> foo = Sub()
>     >>> foo.__bases__
>     [...]
>     AttributeError: 'Sub' object has no attribute '__bases__'
> 
> I'm making this into a new thread, because the particular discussion of 
> whether an object is an instance in Python seems more interesting than 
> discussing whether that error message should be changed or not.
> 
> Here's another example where the terminology keeps indicating that in 
> Python an object is an instance:
> 
>     >>> class Sub:
> 	    pass
> 
>     >>> x = Sub()
>     >>> x
>     <__main__.Sub object at 0x02631690>
> 
> The problem is that I personally cannot agree with this terminology and 
> I would like to hear arguments that could convince me to adopt the 
> Python way. But before your replies, here's my argumentation:
> 
> An instance IS an object. On that we can agree. After all, everything in 
> Python is an object. Even classes are. We can even pass them as function 
> arguments:
> 
>     >>> class Sub:
> 	    pass
> 
>     >>> def show(aClass):
> 	    print(type(aClass))
> 	
>     >>> show(Sub)
>     <class 'type'>
> 
> The problem is that an object isn't always an instance. The word 
> instance in OOP has a very formal meaning. In programming languages in 
> which the classes aren't fully realized objects, it is ok to speak of 
> 'instance' and 'object' interchangeably. But even then, sometimes the 
> term 'object instance' is preferred, as a way to separate these 
> 'instances' from other variable instances that may not be created from 
> class definitions (e.g. C++ built-in types).
> 
> The fact that in Python classes are objects, should not just eliminate 
> this distinction. The OOP terminology should exist beyond the language 
> implementing it. It facilitates discourse and helps transmiting concepts 
> when describing your ideas to another programmer. And because in python, 
> classes are of the type 'type' and they exist as fully realized objects, 
> is no excuse to make a distinction between them and their own fully 
> realized instances. The language implementation details should not exist 
> as a way for us to freely reformulate long standing terms.
> 
> Because, from my own study of Python, I've came to realize that the 
> distinction between objects and instances of objects actually exists. In 
> Python, class objects cannot participate in OOP, only their instances. 
> This is why I say that even in Python, where a class is an object, an 
> object is not always an instance. The language itself forces that 
> distinction.
> 
> ...
> 
> I don't think that any of this is reason enough to rewrite error 
> messages in Python. Seems unnecessary. What I'm arguing thought is that 
> error messages in Python cannot become the source of new terminology. 
> The language itself implements a very clear distinction between class 
> objects and their instances. And it is thus wrong of us to say that 
> Object = Instance. At least from an OOP perspective.

The issue (as I see it) is primarily with English - in particular the word 
'is', technically called copula:
https://en.wikipedia.org/wiki/Copula_%28linguistics%29

Is is(!) used in 3 ways that can get mutually incompatible:
Predication: The sky is blue
Identity: Two plus three is five [Notice how you've used '=' above]
Belonging: (OOP isa relation): Cat is a mammal

Some people have found this (mis|over)use of 'is' so problematic that they have 
suggested to doctor English to not use is as far as possible:
https://en.wikipedia.org/wiki/E-Prime