Everything is an object in python - object class and type class

classic Classic list List threaded Threaded
92 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

random832@fastmail.us
On Mon, Jun 1, 2015, at 21:15, TheDoctor wrote:
> In Python 2.7 type(type) is type (not object), but isinstance(type,
> object) is true -- so it is ambiguous, even contradictory, in the
> language.

isinstance(type, object) is true because object is the parent class of
type. issubclass(type, object) is also true, and that is why
isinstance(int, object) is true. There is no more contradiction than in
anything else being an instance of its own class, its parent class, that
class's parent class, and ultimately... well, object.

type in object.__subclasses__() is also true.
type.__base__ is object.

I could go on.

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

zipher
In reply to this post by Rustom Mody
> > A type is not an object in the same way an instantiated type is an object -- anymore than a blueprint for a building is the building itself.
>
> Point 1
>
> Yes.  You may be onto something here Mark [I assume that's your name].
> Some very intelligent people have suggested that the sloppy use of 'is'
> causes more misunderstanding than any useful communication.
> See http://en.wikipedia.org/wiki/E-Prime.

Ah, yes.  Very good.  Probably relevant.

> And in "G?del, the Mind and the Laws of Physics" Roger Penrose draws a picture
> of Three worlds and the mysteries that connect them
> http://sustainedreaction.yuku.com/topic/4931/Three-Worlds-Three-Mysteries#.VW0b9rzGI8o

Amazing you reference that site.  I used to interact with Ghost Dog who's referenced at the bottom of that post.  Are you familiar with sustainedaction.org?

> 1. The mathematical world
> 2. The mental world
> 3. The physical world
>
> which means that the 'is' in each is different.

Yes.  That's good.

> As enumerated here http://blog.languager.org/2015/03/cs-history-0.html
> the history and very existence of CS has arisen from grapping with these questions.

Interesting, will read up more.

> Point 2: [unrelated to the content of the OP]
> You may wish to consider whether your style and the names you keep assuming
> and changing are helping you.  Best I can see many people have begun to killfile you.

Yes, I know.  The names change based on mood.  The canonical address remains the same.  People are dumb, but perhaps I am dumb for treating them as equals.  Perhaps that's not a fair assumption.  I thought it was polite.

It's quite clear, that there's a bit of religion here and when I come in and point it out, they pull out their Bible and cast me out.  

I get too weary to explain more.  You know how it is arguing to evangelical Christians.  Perhaps another time.

Mark, one of my real names.

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

zipher
In reply to this post by zipher
On Monday, June 1, 2015 at 11:09:09 PM UTC-5, rand... at fastmail.us wrote:

> On Mon, Jun 1, 2015, at 20:24, TheDoctor wrote:
> > A type is not an object in the same way an instantiated type is an object
> > -- anymore than a blueprint for a building is the building itself.
>
> What is an object?
>
> It's something you can call str or repr on. It's something you can
> lookup attributes from its internal dictionary and call methods on. It's
> something you can compare whether it's == to something else. It's
> something you can pass as a parameter to a function

That's good material for relating to the issue. I wish I could justify my position better, but it gets into non-computational arguments.

> In many languages, you can't do any of these things (or their
> equivalents for those languages) to a type. In others, you have to get a
> special "class object" that isn't _really_ the same thing as the type
> itself, via some special syntax like typeof(Foo) or Foo.class, and can
> only work with it through magic methods in a certain module.
>
> In python, you can. Why is this bad or confusing?

It breaks a conceptual barrier.  It's like the difference between seeing an ASCII character symbol and knowing the 8-bit binary digits.  One is a name, the other is the data.  That's an important distinction and they shouldn't be confused in the machine (which can't happen because the machine already creates that boundary).  In the case of the reader though, they can get confused -- they're not interchangeable.  They get "lexed" in the head very differently.

Mark

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Rustom Mody
In reply to this post by zipher
On Tuesday, June 2, 2015 at 10:17:55 AM UTC+5:30, TheDoctor wrote:

>
> Mark, one of my real names.

Thanks -- that helps.

> People are dumb, but perhaps I am dumb for treating them as equals.  Perhaps
> that's not a fair assumption.  

That doesn't.

> It's quite clear, that there's a bit of religion here and when I come in and point it out, they pull out their Bible and cast me out.  
>
> I get too weary to explain more.  You know how it is arguing to evangelical Christians.  Perhaps another time.

Do realize that this is an internation list and so a word like 'religion'
with wildly different connotations in different cultures does not usually aid
communication.
[Sarcasm can communicate when there is a large shared culture else fails miserably]
eg Would it make sense to you if you were told that there are widespread
religions like Buddhism that are agnostic or Jainism that are strictly atheistic?

Reply | Threaded
Open this post in threaded view
|

Religion [was Re: Everything is an object in python - object class and type class]

Steven D'Aprano-11
On Tuesday 02 June 2015 15:01, Rustom Mody wrote:

> eg Would it make sense to you if you were told that there are widespread
> religions like Buddhism that are agnostic or Jainism that are strictly
> atheistic?

No of course it wouldn't make sense. But nothing to do with religion,
spirituality and superstition makes sense, the whole point of them is that
they speak to the emotions, not logic. (You note that I am carefully not
commenting on whether this is a good thing or not.)

Draw up two sets of overlapping axes, and label the vertical axes
"Agnosticism / Gnosticism" and the horizontal axes "Supernatural / Natural".
Belief systems can be found in all four quadrants. Agnostic religions are
easy, they're just in the Supernatural+Agnostic quadrant. If you define
religion to be merely any belief system, then even an atheist religion is
understandable: it could be anything on the Natural half of the graph.

Personally, I consider that redefining religion to refer to belief systems
which do not include supernatural divine gods is an abuse of language
(except informally, as in "football is my religion" or "the religious war
between Vi and Emacs users"). it's like the food processor that is
advertised as being a "three speed food-processor" because there are three
settings on the control: High, Low and OFF.


--
Steve


Reply | Threaded
Open this post in threaded view
|

Religion [was Re: Everything is an object in python - object class and type class]

Rustom Mody
On Tuesday, June 2, 2015 at 11:34:34 AM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 02 June 2015 15:01, Rustom Mody wrote:
>
> > eg Would it make sense to you if you were told that there are widespread
> > religions like Buddhism that are agnostic or Jainism that are strictly
> > atheistic?
>
> No of course it wouldn't make sense. But nothing to do with religion,
> spirituality and superstition makes sense, the whole point of them is that
> they speak to the emotions, not logic.

Emotions dont make sense?
In what sense of 'sense'?
If understanding rather than pronouncing is your intention this may help:
http://en.wikipedia.org/wiki/Triune_brain 
[You may remember a recent poster with the moniker 'PointedEars' in his name
making wild emotional outbursts.  So much for 20th century movie-mythology]

(You note that I am carefully not

> commenting on whether this is a good thing or not.)
>
> Draw up two sets of overlapping axes, and label the vertical axes
> "Agnosticism / Gnosticism" and the horizontal axes "Supernatural / Natural".
> Belief systems can be found in all four quadrants. Agnostic religions are
> easy, they're just in the Supernatural+Agnostic quadrant. If you define
> religion to be merely any belief system, then even an atheist religion is
> understandable: it could be anything on the Natural half of the graph.
>
> Personally, I consider that redefining religion to refer to belief systems
> which do not include supernatural divine gods is an abuse of language
> (except informally, as in "football is my religion" or "the religious war
> between Vi and Emacs users"). it's like the food processor that is
> advertised as being a "three speed food-processor" because there are three
> settings on the control: High, Low and OFF.
>

I am reminded of the TinTin(?) comic:
Telescope informs about a giant alien coming to invade from outer space.
Further examination of telescope shows 'alien' to be a bug (not the software variety)
in the telescope.

Reply | Threaded
Open this post in threaded view
|

Religion [was Re: Everything is an object in python - object class and type class]

Mark Lawrence
In reply to this post by Steven D'Aprano-11
On 02/06/2015 07:04, Steven D'Aprano wrote:

> On Tuesday 02 June 2015 15:01, Rustom Mody wrote:
>
>> eg Would it make sense to you if you were told that there are widespread
>> religions like Buddhism that are agnostic or Jainism that are strictly
>> atheistic?
>
> No of course it wouldn't make sense. But nothing to do with religion,
> spirituality and superstition makes sense, the whole point of them is that
> they speak to the emotions, not logic. (You note that I am carefully not
> commenting on whether this is a good thing or not.)
>
> Draw up two sets of overlapping axes, and label the vertical axes
> "Agnosticism / Gnosticism" and the horizontal axes "Supernatural / Natural".
> Belief systems can be found in all four quadrants. Agnostic religions are
> easy, they're just in the Supernatural+Agnostic quadrant. If you define
> religion to be merely any belief system, then even an atheist religion is
> understandable: it could be anything on the Natural half of the graph.
>
> Personally, I consider that redefining religion to refer to belief systems
> which do not include supernatural divine gods is an abuse of language
> (except informally, as in "football is my religion" or "the religious war
> between Vi and Emacs users"). it's like the food processor that is
> advertised as being a "three speed food-processor" because there are three
> settings on the control: High, Low and OFF.
>
>

If anybody wishes to discuss this can they please take it off list, as
it surely has no place here when we're meant to be discussing the Python
programming langauge.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Steven D'Aprano-11
In reply to this post by zipher
On Tuesday 02 June 2015 11:15, TheDoctor wrote:

> A type is not an object.

Yes it is.


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

> You see it as one, because you are MENTALLY
> lexing your own code on the screen.

No, I see it as one, because it is one.


> But python does not define a type.

Of course it does.

py> isinstance(int, type)  # int is a type
True
py> isinstance(42, type)  # 42 is not a type
False


> It defines certain primitives, like strings and integers.  But it doesn't
> define what an OBJECT is.

In one sense, it does: something is an object if it is an instance of type
"object".

In another sense, it doesn't, because the definition of "object" is bigger
than Python and exists outside of Python. Python had objects before it had a
built-in type called "object".


> So you and everyone else are beating around the
> bush trying to define something that the LANGUAGE ITSELF doesn't define.

Incorrect.


> In Python 2.7 type(type) is type (not object), but isinstance(type,
> object) is true -- so it is ambiguous, even contradictory, in the
> language.

No, it is not ambiguous nor contradictory. It just means that types
(classes), include type itself, are *both* types AND objects. Which is the
whole point of saying that everything is an object! This is not true in all
Object Oriented languages, for instance it is not true in Java, but it is
true in Python.

Notice that we do NOT say that "everything is a type":

py> isinstance(42, type)
False

In Python, all types (classes) are objects, but not all objects (instances)
are types.



--
Steve


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Steven D'Aprano-11
In reply to this post by zipher
On Tuesday 02 June 2015 11:02, TheDoctor wrote:

> On Monday, June 1, 2015 at 7:33:11 PM UTC-5, Chris Angelico wrote:
>> On Tue, Jun 2, 2015 at 10:24 AM, TheDoctor <dreamingforward at gmail.com>
>> wrote:
>> > A type is not an object in the same way an instantiated type is an
>> > object -- anymore than a blueprint for a building is the building
>> > itself.
>>
>> And don't let dreamingforward confuse you, because he is flat-out
>> wrong. An integer is an object, because you can manipulate it as one.
>
> An integer in Python *acts* like an object, in some narrow sense can
> indeed be said to BE one.

No, they *really are* objects. You can look at the source code of the Python
interpreter to see how ints are implemented, and they are implemented as
objects. You can see that they are bigger than a machine int:

py> sys.getsizeof(23)
14

That's 14 bytes. A machine int is typically 2 bytes (int16), 4 bytes (int32)
or 8 bytes (int64).

If you use ctypes, I expect that you can investigate the internal structure
of the int. If not in ctypes, then you can certainly do so from a C
extension.



> But no one uses them like that in practice

Of course they do. ints have methods:

py> n = 23
py> n.to_bytes(5, "big")
b'\x00\x00\x00\x00\x17'


Is that object oriented enough for you?




--
Steve


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Steven D'Aprano-11
In reply to this post by zipher
On Tuesday 02 June 2015 10:24, TheDoctor wrote:

> A type is not an object in the same way an instantiated type is an object
> -- anymore than a blueprint for a building is the building itself.

Nobody says that blueprints are *buildings*. But buildings are not the only
kind of object that exists.

Plates and spoons and knives and forks are objects.
Cars and trucks and ships and planes are objects.
Books and shoes and maps and compasses are objects.
Buildings are objects.
And blueprints of buildings are objects too.


> The reason this confusion appears is for the exact reason I said on an
> earlier thread:  Python does not define classes in it's grammar

Of course it does. Otherwise "class K: pass" would give you a syntax error.


> -- so it
> can't account for the difference between an [instantiated] object and it's
> definition/type.

Of course it can and does. Python has a rich set of tools for introspecting
values and determining whether they are instances or classes, what they are
an instance of, and viewing the differences between the type and the class,
starting with the humble human-readable string representation:

py> type(23)
<class 'int'>

and going on isinstance, issubclass, vars(), dir(), the inspect module, the
dis module, and more.

The simplest test to tell whether something is an instance (an object) is:

isinstance(the_thing, object)

and that returns True *always*. The next test is to check whether it is a
class (a type):

isinstance(the_thing, type)

which returns True only for classes and types. So, classes *are* objects, as
well as being classes -- just as dogs are mammals, as well as being dogs.



--
Steve


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Rustom Mody
On Tuesday, June 2, 2015 at 12:42:31 PM UTC+5:30, Steven D'Aprano wrote:

> On Tuesday 02 June 2015 10:24, TheDoctor wrote:
>
> > A type is not an object in the same way an instantiated type is an object
> > -- anymore than a blueprint for a building is the building itself.
>
> Nobody says that blueprints are *buildings*. But buildings are not the only
> kind of object that exists.
>
> Plates and spoons and knives and forks are objects.
> Cars and trucks and ships and planes are objects.
> Books and shoes and maps and compasses are objects.
> Buildings are objects.
> And blueprints of buildings are objects too.

You are using 'are' as if they are all the same 'are'. Are they?
Consider the type int.
It is supposed to model mathematical integers.
ie 1 ? int (in some sense)

Consider the generator
def int2():
  i = 0
  yield i
  while True:
    yield i
    yield -i

1 ? int2 [Not to mention 1 ? int2()]

Consider range(10) (in python2 and 3)
And finally [1,2,3,4]

1 ? all these
Are the '?'s here same?  Similar?

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Chris Angelico
On Tue, Jun 2, 2015 at 5:44 PM, Rustom Mody <rustompmody at gmail.com> wrote:

>> Plates and spoons and knives and forks are objects.
>> Cars and trucks and ships and planes are objects.
>> Books and shoes and maps and compasses are objects.
>> Buildings are objects.
>> And blueprints of buildings are objects too.
>
> You are using 'are' as if they are all the same 'are'. Are they?
> Consider the type int.
> It is supposed to model mathematical integers.
> ie 1 ? int (in some sense)
>
> Consider the generator
> def int2():
>   i = 0
>   yield i
>   while True:
>     yield i
>     yield -i
>
> 1 ? int2 [Not to mention 1 ? int2()]
>
> Consider range(10) (in python2 and 3)
> And finally [1,2,3,4]
>
> 1 ? all these
> Are the '?'s here same?  Similar?

Yes, they are. Every one of them is asserting (or asking, depending on
your point of view) whether or not the instance to its left is a
member of the set to its right. The sets on the right are all
different, but the set membership operation is identical.

But even more so: The original collection of statements ("are
objects") all used the same RHS. In exactly the same senses, all of
those examples were testing for the same "objectness". (Although you
could argue that Steven's examples were talking about subclass
relationships rather than instance relationships, but really, an
instanceof relationship is a special case of subclass, where the class
on the left is defined by some form of object identity. Stating "All
books are objects" is a subclass relationship; stating "This book is
an object" is an instanceof relationship; both assertions use the same
meaning of "object(s)".)

All shoes are objects.
All ships are objects.
All lumps of sealing-wax are objects.
All cabbages are objects.
All kings are objects. (Some kings are also subjects, but not many.)

I can pick up a shoe, I can look at it, I can verify that it has
certain attributes common to all objects (location, mass, etc).
Superman can do the same with a ship (they're a bit big for me to pick
up). The actions you can perform on all objects are the attributes of
objects in general. Some subclasses of object may provide additional
actions (you can tip a king, for instance), but you can still do all
of these actions, so they're all the same type of object.

Note that not one iota of this has anything to do with Python's
documentation, its rules, its behaviour, or anything. Python follows
the natural expectations of our universe. The standard actions that
can be performed on Python objects are slightly different from the
standard actions that can be performed in Dungeons and Dragons, and
different again from the standard actions of the world we live in, but
they are no less applicable to all objects in that hierarchy:

* You can bind a name to an object (any object).
* You can pass an object as a function parameter.
* You can return an object from a function.
* You can reference objects in other objects' attributes.
* You can distinguish one object from another (that is, objects have
unique identities).

(In CPython, you can recognize an object by its GC header - an object
invariably has a reference count and so on. This is not a fundamental
attribute of objects, but it's a way to recognize them.)

Not everything that Python uses is an object. Syntax is not, itself,
manipulable; you can represent a syntax tree with either source code
(as a string) or an AST object, but syntax itself is not something you
can grasp. You can't assign "foo = def" in Python. But anything that
you can work with, in any way, is an object - and is an instance of
(some subclass of) the type 'object'. So, yes: They ARE all the same
meaning of "are" and "objects".

ChrisA

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Rustom Mody
In reply to this post by Rustom Mody
On Tuesday, June 2, 2015 at 2:08:08 PM UTC+5:30, Chris Angelico wrote:

> On Tue, Jun 2, 2015 at 5:44 PM, Rustom Mody wrote:
> >> Plates and spoons and knives and forks are objects.
> >> Cars and trucks and ships and planes are objects.
> >> Books and shoes and maps and compasses are objects.
> >> Buildings are objects.
> >> And blueprints of buildings are objects too.
> >
> > You are using 'are' as if they are all the same 'are'. Are they?
> > Consider the type int.
> > It is supposed to model mathematical integers.
> > ie 1 ? int (in some sense)
> >
> > Consider the generator
> > def int2():
> >   i = 0
> >   yield i
> >   while True:
> >     yield i
> >     yield -i
> >
> > 1 ? int2 [Not to mention 1 ? int2()]
> >
> > Consider range(10) (in python2 and 3)
> > And finally [1,2,3,4]
> >
> > 1 ? all these
> > Are the '?'s here same?  Similar?
>
> Yes, they are. Every one of them is asserting (or asking, depending on
> your point of view) whether or not the instance to its left is a
> member of the set to its right. The sets on the right are all
> different, but the set membership operation is identical.
>
> But even more so: The original collection of statements ("are
> objects") all used the same RHS. In exactly the same senses, all of
> those examples were testing for the same "objectness". (Although you
> could argue that Steven's examples were talking about subclass
> relationships rather than instance relationships, but really, an
> instanceof relationship is a special case of subclass, where the class
> on the left is defined by some form of object identity. Stating "All
> books are objects" is a subclass relationship; stating "This book is
> an object" is an instanceof relationship; both assertions use the same
> meaning of "object(s)".)
>
> All shoes are objects.
> All ships are objects.
> All lumps of sealing-wax are objects.
> All cabbages are objects.
> All kings are objects. (Some kings are also subjects, but not many.)
>
> I can pick up a shoe, I can look at it, I can verify that it has
> certain attributes common to all objects (location, mass, etc).
> Superman can do the same with a ship (they're a bit big for me to pick
> up). The actions you can perform on all objects are the attributes of
> objects in general. Some subclasses of object may provide additional
> actions (you can tip a king, for instance), but you can still do all
> of these actions, so they're all the same type of object.
>
> Note that not one iota of this has anything to do with Python's
> documentation, its rules, its behaviour, or anything. Python follows
> the natural expectations of our universe. The standard actions that
> can be performed on Python objects are slightly different from the
> standard actions that can be performed in Dungeons and Dragons, and
> different again from the standard actions of the world we live in, but
> they are no less applicable to all objects in that hierarchy:
>
> * You can bind a name to an object (any object).
> * You can pass an object as a function parameter.
> * You can return an object from a function.
> * You can reference objects in other objects' attributes.
> * You can distinguish one object from another (that is, objects have
> unique identities).
>
> (In CPython, you can recognize an object by its GC header - an object
> invariably has a reference count and so on. This is not a fundamental
> attribute of objects, but it's a way to recognize them.)
>
> Not everything that Python uses is an object. Syntax is not, itself,
> manipulable; you can represent a syntax tree with either source code
> (as a string) or an AST object, but syntax itself is not something you
> can grasp. You can't assign "foo = def" in Python. But anything that
> you can work with, in any way, is an object - and is an instance of
> (some subclass of) the type 'object'. So, yes: They ARE all the same
> meaning of "are" and "objects".

Lets take this practically.


>>> isinstance(1,int)
True
>>> 1 in [1,2,3]
True

>>> def int2():
...   i = 0
...   while True:
...    yield i
...    i += 1

>>> 1 in int2()
True
>>>

>>> 1 in range(10)
True

4 True-returning python expressions.  5 if you consider that range in python 2
and 3 are quite different.

Do you consider the computational processes evoked (in the CPython sources) by
these 4 statements to be the same?

[Hint: What does
>>> "shoes" in int2()
return?

And try to take care to distinguish computational from ontological answer
]

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Marko Rauhamaa
In reply to this post by Rustom Mody
Chris Angelico <rosuav at gmail.com>:

> On Tue, Jun 2, 2015 at 5:44 PM, Rustom Mody <rustompmody at gmail.com> wrote:
>> 1 ? all these
>> Are the '?'s here same?  Similar?
>
> Yes, they are. Every one of them is asserting (or asking, depending on
> your point of view) whether or not the instance to its left is a
> member of the set to its right. The sets on the right are all
> different, but the set membership operation is identical.

That is the risk of taking classes into Python. People start to obsess
about membership and ontological relationships. I think you should use
the type() function only for troubleshooting and isinstance() virtually
never.

I think objects should be understood only through their operational
semantics, ie, their methods. It doesn't matter what an object is; what
matters is what it does. Don't test it, just call it.

Yeah, I'm preaching to the choir:

   Alex Martelli made an early (2000) use of the term in a message to
   the comp.lang.python newsgroup:

       In other words, don't check whether it IS-a duck: check whether
       it QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on
       exactly what subset of duck-like behaviour you need to play your
       language-games with.

   <URL: http://en.wikipedia.org/wiki/Duck_typing>


Marko

PS I have written code that violates my stated rule. For example, an
argument could be a string or a list of strings for convenience.
However, this kind of testing should not be performed on anything
created with the "class" keyword. IOW, some types *are* more primitive
than others -- in our minds and in practical use.

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Eddilbert Macharia
In reply to this post by Eddilbert Macharia
On Sunday, May 31, 2015 at 5:34:20 PM UTC+3, Eddilbert Macharia wrote:

> Hello All ,
>
> I'm wrecking my head trying to understand. where the class object comes into play .
>
> Is it only meant to act as base class and does it mean there is an actual class called object in python which all the objects created using the class type inherit ?
>
> i'm assuming the metaclass if simplified would look something like this :
>
> type('dict', (object,),{})
>
> And when we use the class type as a metaclass are we using the instance version of the class type or are we actually using the type class itself ?
>
> Also when we say everything is an object in python, are we referring to the fact that everything is an instance of the class type or does it have to with the object class inherited ?
>
> As can be attested by using type() function as below :
>
> >>> type(int)
> <class 'type'>
> >>> type(list)
> <class 'type'>
> >>> type(dict)
> <class 'type'>
> >>> type(type)
> <class 'type'>
> >>> type(object)
> <class 'type'>
>
> From my understanding this means all of this are instances of the class type. which means the class type was used to create this instances.
>
> Now if i look at the __bases__ of all this objects i get :
>
> >>> type.__base__
> <class 'object'>
> >>> type.__bases__
> (<class 'object'>,)
> >>> dict.__bases__
> (<class 'object'>,)
> >>> list.__bases__
> (<class 'object'>,)
> >>> int.__bases__
> (<class 'object'>,)
> >>> object.__bases__
> ()
>
> This tells me that all of this objects inherit from the class object which has nothing to do with them being instances.

you guys are just confusing me, you are going in loops, and still i have understood ,what makes everything in python an object.
hey is where i'm at :
*** type in python refers to data types e.g. int, str, boolean e.t.c. right ?

*** The interpreter creates two classes type and object when setting up a python environment. right ?

*** The creator (metaclass) of all data types (i.e. int,str) in python is the class type. right ?

>>> isinstance(int,type)
True

*** The instance of class type is a data type an instance of class type. right ?
>>> type(type)
<class 'type'>
>>> isinstance(type,type)
True


*** Class type gets some of its behavior from class object through inheritance.right ?

>>> issubclass(type,object)
True

*** instance of class object is type, in the sense it created using class type which inherits from class object.right ?

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

****so is it right to say, everything in python is an object because they are instance of the class type which inherits from class object ?


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

BartC-3
In reply to this post by BartC-3
On 01/06/2015 23:59, BartC wrote:

>> In the new class style, type and class sort of mean the same thing.
>
> I'm developing a new language along the lines of Python,

(After reading some of the rest of the sub-thread, I'm glad I reined in
some of the proposed changes to my existing language to make it more
Python-like.

If my simple, no-nonsense approach can avoid discussions about
philosophy, religion and meta-physics (or whatever the hell the
sub-thread was about) then that must be a good thing!)

--
Bartc


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Mark Lawrence
In reply to this post by Eddilbert Macharia
On 02/06/2015 11:36, Eddilbert Macharia wrote:
>
> you guys are just confusing me, you are going in loops, and still i have understood ,what makes everything in python an object.

After 14 or more years writing Python I can't really answer that and
quite frankly it doesn't worry me as I can quite happily write working
code, what with practicality beating purity and all that.  Does it worry
you that much?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Rustom Mody
In reply to this post by BartC-3
On Tuesday, June 2, 2015 at 4:16:02 PM UTC+5:30, BartC wrote:

> On 01/06/2015 23:59, BartC wrote:
>
> >> In the new class style, type and class sort of mean the same thing.
> >
> > I'm developing a new language along the lines of Python,
>
> (After reading some of the rest of the sub-thread, I'm glad I reined in
> some of the proposed changes to my existing language to make it more
> Python-like.
>
> If my simple, no-nonsense approach can avoid discussions about
> philosophy, religion and meta-physics (or whatever the hell the
> sub-thread was about) then that must be a good thing!)

What is good that each one can only decide in his own private space.
What is historical is public and studying that history would show that
these questions are central to the existence of our field,
[Mark's views nowithstanding]
http://blog.languager.org/2015/03/cs-history-0.html

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Steven D'Aprano-8
In reply to this post by Eddilbert Macharia
On Tue, 2 Jun 2015 08:36 pm, Eddilbert Macharia wrote:

> you guys are just confusing me, you are going in loops, and still i have
> understood ,what makes everything in python an object. hey is where i'm at
> : *** type in python refers to data types e.g. int, str, boolean e.t.c.
> right ?

Yes. Also classes you create with the "class" keyword:

class K(object):
    ...

K is now a "type", just like int, str, list, object, etc.


> *** The interpreter creates two classes type and object when setting up a
> python environment. right ?

Many more than just two: it also creates list, str, dict, etc. But *first*
it has to create type and object. So you are correct.


> *** The creator (metaclass) of all data types (i.e. int,str) in python is
> the class type. right ?

Correct.

[Aside: I'm only talking about Python 3 here. In Python 2 there is also a
second hierarchy of classes, called "classic classes" or "old-style
classes", which are *not* subclasses of type. But let's just ignore them,
because they are gone in the most recent versions of Python.]


>>>> isinstance(int,type)
> True
>
> *** The instance of class type is a data type an instance of class type.
> right ?
>>>> type(type)
> <class 'type'>

type has many instances, not just one.

Instances of int are individual ints, like 0, 1, 2, 3, ...

Instances of type are individual types, like int, dict, str, list, ...

But one of those many instances of type is, yes, type itself! So *one* of
the instances of type is type, which is also an instance of itself:

>>>> isinstance(type,type)
> True

Correct. This makes type special. Most types are *not* instances of
themselves:

py> isinstance(int, int)
False


> *** Class type gets some of its behavior from class object through
> inheritance.right ?
>
>>>> issubclass(type,object)
> True

Correct.


> *** instance of class object is type, in the sense it created using class
> type which inherits from class object.right ?
>
>>>> isinstance(object,type)
> True
>>>> isinstance(object,object)
> True
>
> ****so is it right to say, everything in python is an object because they
> are instance of the class type which inherits from class object ?

No! That's not what we mean when we say "everything is an object".

Eddilbert, have you programmed in any other languages? It would help you
understand if you have.

"Object" has a general meaning in computer science and programming, it is a
compound data structure that is explicitly linked to a type which provides
functionality that operates on that data structure.

In the programming language C, *no* values are objects. C has types (int16,
uint32, bool, and many more) but no objects.

In the programming language Java, *some* values are objects, and some values
are not objects.

In the programming language Python, *all* values are objects, in the general
sense. That is what we mean by "Everything is an object".

Let's go back in time about 15 years or so. We're now using Python 1.5. In
Python 1.5, there is no built-in object, and type is just a function, not a
class:

>>> import sys
>>> print sys.version
1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)]
>>> object
Traceback (innermost last):
  File "<stdin>", line 1, in ?
NameError: object
>>> type
<built-in function type>


In Python 1.5, classes you create do not inherit from object, because object
does not exist! BUT even in Python 1.5, it is true that everything is an
object.

Remember, "object" can refer to two things:

- *specifically* the class called "object";

- the *general concept* of objects, from object oriented programming.


In Python 1.5:

- everything is an object [the general concept]

- nothing is an instance of the class called "object"


In Python 2:

- everything is an object [the general concept]

- some things, but not all things, are instances of the class
  called "object"


In Python 3:

- everything is an object [the general concept]

- everything is an instance of the class called "object"




--
Steven


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Rustom Mody
On Tuesday, June 2, 2015 at 4:57:31 PM UTC+5:30, Steven D'Aprano wrote:

> On Tue, 2 Jun 2015 08:36 pm, Eddilbert Macharia wrote:
>
> > you guys are just confusing me, you are going in loops, and still i have
> > understood ,what makes everything in python an object. hey is where i'm at
> > : *** type in python refers to data types e.g. int, str, boolean e.t.c.
> > right ?
>
> Yes. Also classes you create with the "class" keyword:
>
> class K(object):
>     ...
>
> K is now a "type", just like int, str, list, object, etc.
>
>
> > *** The interpreter creates two classes type and object when setting up a
> > python environment. right ?
>
> Many more than just two: it also creates list, str, dict, etc. But *first*
> it has to create type and object. So you are correct.
>
>
> > *** The creator (metaclass) of all data types (i.e. int,str) in python is
> > the class type. right ?
>
> Correct.
>
> [Aside: I'm only talking about Python 3 here. In Python 2 there is also a
> second hierarchy of classes, called "classic classes" or "old-style
> classes", which are *not* subclasses of type. But let's just ignore them,
> because they are gone in the most recent versions of Python.]
>
>
> >>>> isinstance(int,type)
> > True
> >
> > *** The instance of class type is a data type an instance of class type.
> > right ?
> >>>> type(type)
> > <class 'type'>
>
> type has many instances, not just one.

Not sure what you are trying to emphasize by the 'not just one'
In particular the issubclass relation is transitive
Whereas the isinstance is not

>>> isinstance(2,int)
True
>>> isinstance(int,type)
True
>>> isinstance(2,type)
False

12345