An object is an instance (or not)?

André Roberge andre.roberge at
Tue Jan 27 21:50:05 CET 2015

On Tuesday, 27 January 2015 16:12:47 UTC-4, 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.

You keep writing "an object is not an instance", making statements such as "the terminology keeps indicating that in Python an object is an instance" and yet, none of the examples you show from Python (tracebacks or repr outputs) include the word "instance".   

To phrase it differently: all the examples of output from Python that you show use the word "object" and not the word "instance".  Yet **you** claim that "Python" states that objects are instances ....    Can you point out at least one example where "Python" wrongly use the word instance instead of object?

More information about the Python-list mailing list