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 -- https://mail.python.org/mailman/listinfo/python-list
