Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #84665 > unrolled thread

An object is an instance (or not)?

Back to article view | Back to comp.lang.python

Contents

  An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-27 21:12 +0100
    Re: An object is an instance (or not)? Ethan Furman <ethan@stoneleaf.us> - 2015-01-27 12:36 -0800
    Re: An object is an instance (or not)? André Roberge <andre.roberge@gmail.com> - 2015-01-27 12:50 -0800
      Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-27 22:06 +0100
        Re: An object is an instance (or not)? André Roberge <andre.roberge@gmail.com> - 2015-01-27 13:38 -0800
          Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-27 22:43 +0100
            Re: An object is an instance (or not)? André Roberge <andre.roberge@gmail.com> - 2015-01-27 13:49 -0800
              Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-27 22:58 +0100
                Re: An object is an instance (or not)? Ben Finney <ben+python@benfinney.id.au> - 2015-01-28 09:32 +1100
                  Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 18:55 +1100
                    Re: An object is an instance (or not)? Ben Finney <ben+python@benfinney.id.au> - 2015-01-28 22:20 +1100
                Re: An object is an instance (or not)? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-27 23:12 +0000
                  Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-28 01:52 +0100
                    Re: An object is an instance (or not)? Marko Rauhamaa <marko@pacujo.net> - 2015-01-28 07:25 +0200
                      Re: An object is an instance (or not)? Rustom Mody <rustompmody@gmail.com> - 2015-01-27 21:53 -0800
                    Re: An object is an instance (or not)? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-28 05:57 +0000
                      Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-28 11:48 +0100
        Re: An object is an instance (or not)? random832@fastmail.us - 2015-01-28 00:37 -0500
          Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 19:45 +1100
        Re: An object is an instance (or not)? Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-27 21:43 -0800
        Re: An object is an instance (or not)? random832@fastmail.us - 2015-01-28 01:01 -0500
          Re: An object is an instance (or not)? Rustom Mody <rustompmody@gmail.com> - 2015-01-27 22:22 -0800
            Re: An object is an instance (or not)? Ben Finney <ben+python@benfinney.id.au> - 2015-01-28 18:03 +1100
          Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 19:48 +1100
        Re: An object is an instance (or not)? Ben Finney <ben+python@benfinney.id.au> - 2015-01-28 17:59 +1100
        Re: An object is an instance (or not)? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-28 20:21 +1300
        Re: An object is an instance (or not)? Ben Finney <ben+python@benfinney.id.au> - 2015-01-28 18:48 +1100
        Re: An object is an instance (or not)? random832@fastmail.us - 2015-01-28 12:08 -0500
          Re: An object is an instance (or not)? Rustom Mody <rustompmody@gmail.com> - 2015-01-28 18:29 -0800
    Re: An object is an instance (or not)? Ned Batchelder <ned@nedbatchelder.com> - 2015-01-27 18:22 -0500
      Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-28 01:17 +0100
        Re: An object is an instance (or not)? Chris Angelico <rosuav@gmail.com> - 2015-01-28 11:30 +1100
          Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-28 01:35 +0100
            Re: An object is an instance (or not)? alex23 <wuwei23@gmail.com> - 2015-01-28 14:44 +1000
            Re: An object is an instance (or not)? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-28 23:33 +1300
              Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 22:52 +1100
                Re: An object is an instance (or not)? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-29 19:22 +1300
                  Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-29 18:16 +1100
                    Re: An object is an instance (or not)? Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-29 08:48 -0700
                    Re: An object is an instance (or not)? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-30 22:07 +1300
                      Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 10:45 +1100
        Re: An object is an instance (or not)? Ned Batchelder <ned@nedbatchelder.com> - 2015-01-27 21:21 -0500
          Re: An object is an instance (or not)? Rustom Mody <rustompmody@gmail.com> - 2015-01-27 18:52 -0800
          Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 20:16 +1100
            Re: An object is an instance (or not)? Chris Angelico <rosuav@gmail.com> - 2015-01-28 21:01 +1100
              Re: An object is an instance (or not)? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-29 14:22 -0800
        Re: An object is an instance (or not)? Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-27 19:15 -0700
        Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 20:28 +1100
        Re: An object is an instance (or not)? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-28 23:33 +1300
      Re: An object is an instance (or not)? Grant Edwards <invalid@invalid.invalid> - 2015-01-28 00:23 +0000
    Re: An object is an instance (or not)? Ben Finney <ben+python@benfinney.id.au> - 2015-01-28 10:39 +1100
      Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-28 01:24 +0100
        Re: An object is an instance (or not)? Ben Finney <ben+python@benfinney.id.au> - 2015-01-28 12:00 +1100
          Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-28 02:14 +0100
        Re: An object is an instance (or not)? alex23 <wuwei23@gmail.com> - 2015-01-28 14:47 +1000
          Re: An object is an instance (or not)? Rustom Mody <rustompmody@gmail.com> - 2015-01-27 21:23 -0800
          Re: An object is an instance (or not)? random832@fastmail.us - 2015-01-28 00:44 -0500
            Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 20:21 +1100
        Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 20:17 +1100
      Re: An object is an instance (or not)? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 20:09 +1100
    Re: An object is an instance (or not)? Chris Angelico <rosuav@gmail.com> - 2015-01-28 10:42 +1100
      Re: An object is an instance (or not)? Mario Figueiredo <marfig@gmail.com> - 2015-01-28 01:31 +0100
    Re: An object is an instance (or not)? Rustom Mody <rustompmody@gmail.com> - 2015-01-27 18:11 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#84924

Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> Actually, if you look at my example, you will see that it is a method and
>> it does get the self argument. Here is the critical code again:
>> 
>> from types import MethodType
>> polly.talk = MethodType(
>>     lambda self: print("Polly wants a spam sandwich!"), polly)
> 
> Doing it by hand is cheating.

Smile when you say that, pardner :-)

I don't see why you think I'm cheating. What rule do you think is being
broken? I want to add a method to the instance itself, so I create a method
object and put it on the instance. What should I have done?

The default metaclass ("type") only applies the descriptor protocol to
attributes retrieved from the class itself, not those retrieved from the
instance. For instance, you can add a property object onto the instance,
but it won't behave as a property:

py> class K(object):
...     pass
...
py> x = K()
py> x.spam = property(lambda self: 23)
py> x.spam
<property object at 0xb7bbcb44>


But if I add it to the class, the descriptor magic happens:

py> K.eggs = x.spam
py> x.eggs
23

Functions are descriptors, just like property objects! So an alternative to
manually making a method object would be to use a metaclass that extended
the descriptor protocol to instance attributes. I suppose you would call
that "cheating" too?

But all of this is a side-show that distracts from my point, which is that
the lookup rules for instances and classes are such that you can override
behaviour defined in the class on a per-instance basis. The mechanics of
such aren't really relevant.


>> That's certainly not correct, because Python had classes and instances
>> before it had descriptors!
> 
> Before the descriptor protocol, a subset of its functionality
> was hard-wired into the interpreter. There has always been
> some magic going on across the instance-class boundary that
> doesn't occur across the class-baseclass boundary.

Yes, but that magic is effectively "implementation, not interface". I put
that in scare quotes because in actual pedantic fact, the descriptor
protocol is an interface: we can write our own custom descriptors. I don't
dispute that's important.

But from a birds eye view, and looking at just method and regular attribute
access, the relationship between instance-class and class-baseclass is very
similar, as is that between class-metaclass, and descriptor magic is merely
part of the implementation to make things work.

I daresay you are right that there are a few places where the interpreter
treats classes as a distinct and different kind of thing than non-class
instances. One obvious place is that dunder methods are not looked up on
the instance, unlike pretty much everything else. But I did preface my
comments about attribute lookup order as being simplified, so you can
probably find a lot more to criticise if you wish :-)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#84706

On 1/27/15 7:17 PM, Mario Figueiredo wrote:
> In article <mailman.18191.1422400930.18130.python-list@python.org>,
> ned@nedbatchelder.com says...
>>
>> A common mistake is to believe that "OOP" is a well-defined term.  It's
>> not it's a collection of ideas that are expressed slightly differently
>> in each language.
>
> A common mistake is thinking just because OOP has different
> implementations, it doesn't have a cohesive set of well described rules
> and its own well defined terminology.

I know you think that it has well described rules and terminology.  But 
take a look at this discussion, and maybe realize that the terms are not 
as well-defined, or certainly not as widely accepted as you think.

Do you have a reference that defines these terms?

>
>> I don't know what a "not fully realized object" is.
>
> A fully realized object, in an object oriented paradigm, is an object
> containing or pointing to data and the methods to act on that data. It's
> an instance of a class.
>
> A *not* fully realized object is possible in Python, since Classes are
> first-class objects, despite not being able to participate in OOP.
>>
>> What does "participate in OOP" mean?
>
> Means the object is capable of participating in inheritance and/or
> polymorphism. An instance of an object is capable of doing so, per its
> class definitions. Whereas a Python class object is not.
>
>      >>> class Master:
>              def func(self):
>                  pass
>
>      >>> class Sub(Master):
>              pass
>
>      >>> Sub.func()
>      TypeError: func() missing 1 required positional argument: 'self'


> But somehow I think you knew the answer to all these questions and were
> instead being snarky.

I am not being snarky, I'm trying to understand where our mutual 
incomprehension lies.


-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#84708

On Wednesday, January 28, 2015 at 7:55:12 AM UTC+5:30, Ned Batchelder wrote:
> On 1/27/15 7:17 PM, Mario Figueiredo wrote:
> > Ned Batchelder says...
> >>
> >> A common mistake is to believe that "OOP" is a well-defined term.  It's
> >> not it's a collection of ideas that are expressed slightly differently
> >> in each language.
> >
> > A common mistake is thinking just because OOP has different
> > implementations, it doesn't have a cohesive set of well described rules
> > and its own well defined terminology.
> 
> I know you think that it has well described rules and terminology.  But 
> take a look at this discussion, and maybe realize that the terms are not 
> as well-defined, or certainly not as widely accepted as you think.

I'd go a step or two further than that.

Here's a discussion almost isomorphic [including Ned's futile attempts at
inducing sanity] to this one from a few years ago
https://groups.google.com/d/msg/comp.lang.python/y6mnzDeEsRU/Wvpo4mJ-a2gJ
[And others by that same OP - Mark Janssen - zipher]¹

And there's the recent one (2 because of thread breaking) on
<<Comparisons and sorting of a numeric class>>

To me all these suggest that OOP as a philosophy pickles the brain.
And violently passionate adherence to the philosophy conduces to madness.

[Reminded of a quote I saw on the scheme mailing list:
OOP is the phlogiston theory of CS
]

====================
¹ To those who suffer violent allergic reactions on seeing ...groups.google... the numbering of the official archive is so fluid that even
google (search engine!) is getting confused and pointing to broken links

[toc] | [prev] | [next] | [standalone]

#84732

Ned Batchelder wrote:

> Do you have a reference that defines these terms?

*A* reference is not sufficient. It has to be a reference which all other 
references agree with.

I'll be kind, and lower the requirement to one where *the majority* of other 
references agree. The OP still won't find one :-)

Or perhaps that should be a sad face smiley :-( How much time we would all 
save if academics and language designers would only stick to a single 
consistent terminology across all languages.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#84737

On Wed, Jan 28, 2015 at 8:16 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Or perhaps that should be a sad face smiley :-( How much time we would all
> save if academics and language designers would only stick to a single
> consistent terminology across all languages.

That's like wishing that every human spoke the same language, instead
of having English, French, Italian, Polish, Serbian, Korean, and a
host of others. The problem isn't the languages; the variety of
languages reflects a variety of concepts being communicated, and to
unify the languages spoken would entail dispensing with that variety.

The terminology isn't consistent because there are myriad variations
between the concepts. Is it useful to talk about "multiple
inheritance" as a concept? I believe I've yet to meet two distinct
languages that have identical MI semantics. Does each language need
its own word for that term so we don't have any sort of
inconsistencies? Or do all languages have to implement the exact same
functionality?

ChrisA

[toc] | [prev] | [next] | [standalone]

#84848

On Wednesday, January 28, 2015 at 4:01:41 AM UTC-6, Chris Angelico wrote:
> On Wed, Jan 28, 2015 at 8:16 PM, Steven D'Aprano wrote:
> > Or perhaps that should be a sad face smiley :-( How much
> > time we would all save if academics and language
> > designers would only stick to a single consistent
> > terminology across all languages.
>
> That's like wishing that every human spoke the same
> language, instead of having English, French, Italian,
> Polish, Serbian, Korean, and a host of others. The problem
> isn't the languages; the variety of languages reflects a
> variety of concepts being communicated,

Yes guys, because everyone knows that "selfish adolescent
accessorizing" is the *KEY* to building a sane human
knowledge base! I mean, who needs a single word (or grunt)
to mean, say, "cat-herding", when infinitely more selfish
incarnations can be invented on the fly!!!

##########################
# Untested Code:
##########################

 def pollute_the_database(concept):
     for region in world.regions:
         # XXX: Avoid buffer overflows!
         grunt = region.generate_grunt(concept)
         database.setdefault(concept, {"aliases":[]})
         database[concept]["aliases"].append(str(grunt))

 if __game__ == "__existentialism__":
     concepts = humans.collectiveConciseness
     database = humans.collectiveDatabase
     while len(concepts) > 0:
         # XXX: Make thread safe!
         conceptN = concepts.pop()
         if is_selfishly_infantile(humans):
             pollute_the_database(conceptN)
         else:
             # Dead code follows :-'(
             word = world.generate_grunt(conceptN)
             database[concept] = word

[toc] | [prev] | [next] | [standalone]

#84707

On Tue, Jan 27, 2015 at 5:17 PM, Mario Figueiredo <marfig@gmail.com> wrote:
> In article <mailman.18191.1422400930.18130.python-list@python.org>,
> ned@nedbatchelder.com says...
>> What does "participate in OOP" mean?
>
> Means the object is capable of participating in inheritance and/or
> polymorphism. An instance of an object is capable of doing so, per its
> class definitions. Whereas a Python class object is not.

Python class objects are capable of doing both these things.

>     >>> class Master:
>             def func(self):
>                 pass
>
>     >>> class Sub(Master):
>             pass
>
>     >>> Sub.func()
>     TypeError: func() missing 1 required positional argument: 'self'

You get the same result by calling Master.func(), so I don't see how
this is a counter-example. Anyway, here is how class objects
participate in inheritance:

class BaseMetaClass(type):
    def func(cls):
        return 42

class DerivedMetaClass(BaseMetaClass):
    pass

class DerivedClass(metaclass=DerivedMetaClass):
    pass

>>> isinstance(DerivedClass, BaseMetaClass)
True
>>> print(DerivedClass.func())
42

Note that this is exactly the same way that non-class objects
participate in inheritance. Instances don't simply inherit from other
instances. Rather, the class of the instance inherits from other
classes and provides methods to the instances. And that's what happens
here: the class's meta class inherits from another, and the method it
defines is callable on the instance.

[toc] | [prev] | [next] | [standalone]

#84735

Mario Figueiredo wrote:

> In article <mailman.18191.1422400930.18130.python-list@python.org>,
> ned@nedbatchelder.com says...
>> 
>> A common mistake is to believe that "OOP" is a well-defined term.  It's
>> not it's a collection of ideas that are expressed slightly differently
>> in each language.
> 
> A common mistake is thinking just because OOP has different
> implementations, it doesn't have a cohesive set of well described rules
> and its own well defined terminology.

Alas, this is not a mistake. As I posted in a reply to Ben, OOP does not 
have a cohesive set of rules and well-defined terminology.


>> I don't know what a "not fully realized object" is.
> 
> A fully realized object, in an object oriented paradigm, is an object
> containing or pointing to data and the methods to act on that data. It's
> an instance of a class.

In Python, classes meet that definition too. A class in Python is a value 
which can contain data (or point to data), and it has methods which act on 
that data. Classes in Python themselves have a class, which we call the 
metaclass, and classes inherit behaviour from their class just as integer 
instances inherit behaviour from their class, int.


> A *not* fully realized object is possible in Python, since Classes are
> first-class objects, despite not being able to participate in OOP.
> 
>> 
>> What does "participate in OOP" mean?
> 
> Means the object is capable of participating in inheritance and/or
> polymorphism. An instance of an object is capable of doing so, per its
> class definitions. Whereas a Python class object is not.

Class objects are capable of participating in inheritance. A class can have 
multiple metaclasses. They can even have multiple inheritance of 
metaclasses.

I'm not sure what relevance polymorphism has.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#84739

Mario Figueiredo wrote:
> An instance of an object is capable of doing so, per its 
> class definitions. Whereas a Python class object is not.
> 
>     >>> class Master:
>             def func(self):
>                 pass
> 
>     >>> class Sub(Master):
>             pass
> 
>     >>> Sub.func()
>     TypeError: func() missing 1 required positional argument: 'self'

But Sub is not an *instance* of Master here, it's
a *subclass* of Master, which is quite a different
thing:

 >>> Sub.__class__
<class 'type'>

To make Sub be an *instance* of Master, you need to
do this. (NOTE: This is Python 3 syntax; the same
thing can be done in Python 2, but the syntax is
slightly different.)

 >>> class Master(type):
...  def func(self):
...   print("func of", self, "called")
...
 >>> class Sub(metaclass = Master):
...  pass
...
 >>> Sub.__class__
<class '__main__.Master'>
 >>> Sub.func()
func of <class '__main__.Sub'> called

So, you see, Python classes *can* participate in OOP
just as fully as any other object. You just need to
know how to do it correctly.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#84689

On 2015-01-27, Ned Batchelder <ned@nedbatchelder.com> wrote:
> On 1/27/15 3:12 PM, 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.
>
> I don't know what the difference is between "object" and "instance".  An 
> object is an instance of a class.  The two words are interchangeable as 
> far as I know.

They are interchangable in recent versions of Python.

--
Grant

[toc] | [prev] | [next] | [standalone]

#84685

Ned Batchelder <ned@nedbatchelder.com> writes:

> On 1/27/15 3:12 PM, 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.
>
> I don't know what the difference is between "object" and "instance".
> An object is an instance of a class.  The two words are
> interchangeable as far as I know.

Not in English grammar, IMO. To say “foo is an instance” implies the
sentence isn't finished; the term “instance” only makes sense in the
context of a relationship to some class. To say “foo is an object”
doesn't have that implication.

> A common mistake is to believe that "OOP" is a well-defined term.
> It's not it's a collection of ideas that are expressed slightly
> differently in each language.

Right. The common meaning of “object” shared by all OOP systems is
surprisingly small.

Many OOP systems do not use classes (e.g. JavaScript) and are no less
object-oriented for that. In such a system it would be true to say “foo
is an object, but is not an instance of anything”.

> > 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.
>
> What does "participate in OOP" mean?

To the extent I understand (and I'm confused on what that might mean as
you are), I think it's plainly false.

In Python, every class is an object. Every class has the full range of
behaviour that we expect of objects. A class just has the additional
feature that it can be instantiated.

> > 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.

You have not, to my knowledge, shown any object (in Python 2.2 or later)
which is not an instance of some class. Python objects are always an
instance of some specific class.

-- 
 \     “Books and opinions, no matter from whom they came, if they are |
  `\     in opposition to human rights, are nothing but dead letters.” |
_o__)                                                  —Ernestine Rose |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#84690

In article <mailman.18192.1422401989.18130.python-list@python.org>, 
ben+python@benfinney.id.au says...
> > > 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.
> 
> You have not, to my knowledge, shown any object (in Python 2.2 or later)
> which is not an instance of some class. Python objects are always an
> instance of some specific class.

It is true that a class object is an instance of 'type'. But this is a 
special type (can't avoid the pun). A class object is not an instance of 
the type it implements. That is what I mean by an object that isn't an 
instance.

In other words, the object know as "Sub class" is not an instance 
object. True, it is an instance of the object 'type'.

[toc] | [prev] | [next] | [standalone]

#84696

Mario Figueiredo <marfig@gmail.com> writes:

> It is true that a class object is an instance of 'type'. But this is a
> special type (can't avoid the pun).

Nevertheless it is a class, and can do everything that classes do.

And every class is an object, and can do everything that objects do.

You seem to agree with those, so please stop claiming that classes are
not objects. Python classes are always objects, and always have been.

> A class object is not an instance of the type it implements.

You keep introducing hurdles that are irrelevant. Yes, a class is not an
instance of itself. That doesn't impact the fact a class is an object.

> That is what I mean by an object that isn't an instance.

That's incoherent. It's an instance of a class, and simultaneously is
not an instance?

> In other words, the object know as "Sub class" is not an instance 
> object. True, it is an instance of the object 'type'.

You've tied yourself in knots with concepts that are not coherent, and
even if they were do not appear to be relevant to Python.

-- 
 \      “Very few things happen at the right time, and the rest do not |
  `\     happen at all. The conscientious historian will correct these |
_o__)                          defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#84698

In article <mailman.18196.1422406856.18130.python-list@python.org>, 
ben+python@benfinney.id.au says...
> 
> Mario Figueiredo <marfig@gmail.com> writes:
> 
> > It is true that a class object is an instance of 'type'. But this is a
> > special type (can't avoid the pun).
> 
> Nevertheless it is a class, and can do everything that classes do.
> 
> And every class is an object, and can do everything that objects do.
> 
> You seem to agree with those, so please stop claiming that classes are
> not objects. Python classes are always objects, and always have been.
> 
> > A class object is not an instance of the type it implements.
> 
> You keep introducing hurdles that are irrelevant. Yes, a class is not an
> instance of itself. That doesn't impact the fact a class is an object.
> 
> > That is what I mean by an object that isn't an instance.
> 
> That's incoherent. It's an instance of a class, and simultaneously is
> not an instance?
> 
> > In other words, the object know as "Sub class" is not an instance 
> > object. True, it is an instance of the object 'type'.
> 
> You've tied yourself in knots with concepts that are not coherent, and
> even if they were do not appear to be relevant to Python.

Very well. I'm failing at putting my point across. I will not discuss 
this further.

[toc] | [prev] | [next] | [standalone]

#84711

On 28/01/2015 10:24 AM, Mario Figueiredo wrote:
> In other words, the object know as "Sub class" is not an instance
> object. True, it is an instance of the object 'type'.

     >>> class Foo:
     ...     pass
     ...
     >>> isinstance(Foo, type)
     True
     >>> isinstance(Foo, object)
     True

A class is an object that is an instance of the class type. I'm still 
failing to see what distinction you're trying to make here.

[toc] | [prev] | [next] | [standalone]

#84712

On Wednesday, January 28, 2015 at 10:18:07 AM UTC+5:30, alex23 wrote:
> On 28/01/2015 10:24 AM, Mario Figueiredo wrote:
> > In other words, the object know as "Sub class" is not an instance
> > object. True, it is an instance of the object 'type'.
> 
>      >>> class Foo:
>      ...     pass
>      ...
>      >>> isinstance(Foo, type)
>      True
>      >>> isinstance(Foo, object)
>      True
> 
> A class is an object that is an instance of the class type. I'm still 
> failing to see what distinction you're trying to make here.

Confusion is not disallowed is it ;-)
Maybe some diagrams will help. Something like
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.631&rep=rep1&type=pdf
pic on page 7 particularly the distinction between the arrows and the dotted arrows

[toc] | [prev] | [next] | [standalone]

#84716

On Tue, Jan 27, 2015, at 23:47, alex23 wrote:
> On 28/01/2015 10:24 AM, Mario Figueiredo wrote:
> > In other words, the object know as "Sub class" is not an instance
> > object. True, it is an instance of the object 'type'.
> 
>      >>> class Foo:
>      ...     pass
>      ...
>      >>> isinstance(Foo, type)
>      True
>      >>> isinstance(Foo, object)
>      True
> 
> A class is an object that is an instance of the class type. I'm still 
> failing to see what distinction you're trying to make here.

I think his objection is to the use of the phrase "'Sub' object" to
refer only to instances of the Sub type, when 'Sub' is the name of the
type object itself and therefore (he thinks) "'Sub' object" should refer
to it instead. (I can only assume he wants "'x' object" for x = Sub().)

[toc] | [prev] | [next] | [standalone]

#84734

random832@fastmail.us wrote:

> I think his objection is to the use of the phrase "'Sub' object" to
> refer only to instances of the Sub type, when 'Sub' is the name of the
> type object itself and therefore (he thinks) "'Sub' object" should refer
> to it instead. (I can only assume he wants "'x' object" for x = Sub().)


Yes, that's exactly what Mario asked for in the original thread that started 
this. Sadly Python cannot do this.

But the docs could consistently use "class" or "type" to refer to classes 
and types (in Python 3, they are the same thing), and "instance" to refer to 
instances which are not classes, and "object" to refer to both.

And then I would be sooooooo happyyyyyy :-)


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#84733

Mario Figueiredo wrote:

> In other words, the object know as "Sub class" is not an instance
> object. True, it is an instance of the object 'type'.


Can you not see the contradiction there?

The object known as 42 is not an instance object. True, it is an instance of 
the object "int".

Er, then surely that means that 42 *is* an instance object?

I agree that in *common situations*, it is useful to pretend that Python is 
like Java, and draw a distinction between classes and instances. I don't 
think it is useful to deny that classes are instances.

The discussion depends on context, in the same way that depending on context 
sometimes it is useful to include Homo sapiens in the group "Animals" and 
sometimes not:

"Sit up straight and stop eating like an animal!"

"Like all animals, human beings rely on the environment for their survival."


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#84731

Ben Finney wrote:

> Ned Batchelder <ned@nedbatchelder.com> writes:
> 
>> On 1/27/15 3:12 PM, 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.
>>
>> I don't know what the difference is between "object" and "instance".
>> An object is an instance of a class.  The two words are
>> interchangeable as far as I know.
> 
> Not in English grammar, IMO. To say “foo is an instance” implies the
> sentence isn't finished; the term “instance” only makes sense in the
> context of a relationship to some class. To say “foo is an object”
> doesn't have that implication.

I'm sure that there is a grammatical term for this, but I don't know it. 
Regardless of the terminology though, "foo is an instance" is a complete 
sentence fragment:

"foo is an instance" (of some unspecified class)

is the same grammatical construct as:

"George is a soldier" (of some unspecified army)
"Pluto is a cartoon animal" (of some unspecified species)
"Bearhugger's Old Peculiar is a drink" (of some unspecified type)
"Herbie is a car" (of some unspecified make and model)

etc. In Java, the term "object" as a synonym for "instance" is unambiguous, 
because in Java all classes are subclasses of Object, and no classes are 
themselves instances of a class. But that's not the case with Python.


>> A common mistake is to believe that "OOP" is a well-defined term.
>> It's not it's a collection of ideas that are expressed slightly
>> differently in each language.
> 
> Right. The common meaning of “object” shared by all OOP systems is
> surprisingly small.

Agreed. There really is no widespread agreement on what OOP means 
*precisely*. Wikipedia states:

"Attempts to find a consensus definition or theory behind objects have not 
proven very successful" and there is little agreement of the fundamental 
features of OOP:

http://en.wikipedia.org/wiki/Object-
oriented_programming#Fundamental_features_and_concepts


[...] 
> In Python, every class is an object. Every class has the full range of
> behaviour that we expect of objects. A class just has the additional
> feature that it can be instantiated.

We can also define an "is-a" relationship between classes and their 
instances:

[1, 2, "spam"] is-a list;

but not list is-a [1, 2, "spam"]


However, in Python that breaks down at the very bottom of the inheritance 
hierarchy, thanks to the circular relationship between type and object:

py> isinstance(type, object)
True
py> isinstance(object, type)
True

type is-a object
object is-a type



-- 
Steve

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web