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

BartC-3
On 02/06/2015 12:27, Steven D'Aprano wrote:

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

The C Standard has hundreds of references to 'object'.

C objects are also linked to a type but it doesn't need to be explicit
/in the run-time data/ because it's a static language. The compiler
knows all the types because there are explicit annotations in the source
code.

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

In a dynamically typed language such as Python, you need to be able to
deal with values consistently whatever their type, simply because you
can't tell what the types are from source code. (Not without a lot of
work which Python doesn't attempt, although RPython might do so.) Example:

  print (a)

a might be the int 42, or a it might be a million-element list. So both
are wrapped up as 'objects'.

Java is statically typed which makes it possible to treat instance
variables differently without needing to examine their types at runtime.
If you define 'object' in a certain way (eg. as boxed, tagged data),
then it follows that some values don't need to be objects.

--
Bartc

Reply | Threaded
Open this post in threaded view
|

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

Marko Rauhamaa
BartC <bc at freeuk.com>:

> If you define 'object' in a certain way (eg. as boxed, tagged data),
> then it follows that some values don't need to be objects.

The word "object" really barely carries any meaning -- that's the point.
It's a Latin-based synonym of the Germanic "thing."

To say that everything is an object in Python simply means that the same
set of concepts applies to all data. The main distinguishing feature
between Python objects is mutability.

The utmost abstraction of everything into an object is the pinnacle of
understanding. The question is, should a beginning Python programmer
start the climb from the summit or from the root of the mountain. IOW,
does it help to start the Python journey by learning that numbers are
objects, given that the language gives lots of special treatment to
numbers (as well as strings, lists and functions, for example)?

I would imagine that the gentlest route to Python programming starts
without talking much about objects at all. Leave the discussion about
numbers as objects till after, say, multiple inheritance has been
covered. Then, things like strings as objects and regular expression
match objects can be brought in naturally, and expressions like

   ','.join(person.name
            for person in persons
            if person.is_underage())

no longer defy comprehension.


Marko

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 Rustom Mody
On Tue, 2 Jun 2015 09:40 pm, Rustom Mody wrote:

> 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:
[...]
>> > *** 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'

The OP says "THE [emphasis added] instance of class type" -- type has more
than one instance.


> In particular the issubclass relation is transitive
> Whereas the isinstance is not

Why is that relevant?


--
Steven


Reply | Threaded
Open this post in threaded view
|

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

Ian Kelly-2
In reply to this post by BartC-3
On Mon, Jun 1, 2015 at 4:59 PM, BartC <bc at freeuk.com> wrote:

> I'm developing a new language along the lines of Python, perhaps a brief
> description of how things are done there might help. Or just give a
> different perspective.
>
> Objects in this language are tagged: there's a code attached to each
> indicating what kind of data is stored. These codes are integers, or
> enumerations, for example:
>
>  Int =    1
>  String = 2
>  List =   3
>  Class =  4
>
> And the following are examples of object instances with their tags:
>
> a is (Int,    42)
> b is (String, "ABCXYZ")
> c is (List,   [10,20,30,40])
> d is (Class,  2 or <String>)
>
> The last one might be tricky to grasp: it's really just a number, but one
> that represents a class or type (or tag). If printed, it could display
> <String> rather than just 2. (And when used to do something with the class,
> the 2 might be an index into a set of tables.)
>
> d is not /the/ class itself, but just a reference to it (this is pseudo-code
> not Python):
>
> print (b)                 =>  ABCXYZ
> print (typeof(b))         =>  String <2>
>
> print (d)                 =>  String <2>
> print (typeof(d))         =>  Class  <4>
> print (typeof(typeof(d))) =>  Class  <4>
>
> In my own language, the connection between class and type is hazy (I've only
> just added classes so it needs to be hazy until I understand them more).
>
> 'Type' includes everything, including all the built-in types such as the
> tags above, but also user-defined classes. In fact classes are the mechanism
> used to define new types. But with both designated by an integer within the
> same band (eg. built-int types 1 to 20, user-defined classes 21 and up), it
> is easier not to have a strong distinction ... at the moment.
>
> I haven't a root class yet that is the base of all the others. I don't think
> it's necessary internally to make things work. But it might be a useful
> concept in the language. Calling it 'object' however might give rise to
> confusion as 'object' is informally used to refer to instances. (I've never
> used OO but have picked up some of the jargon!)
>
> (This is almost certainly not how Python does things. Although the Python
> language doesn't go into details as to its implementation provided the
> behaviour is correct.)

It sounds quite similar to me. In CPython at least, every object has a
direct pointer to its type rather than an array index (which is
essentially just an offset from a pointer).

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 Steven D'Aprano-8
On Tuesday, June 2, 2015 at 8:38:42 PM UTC+5:30, Steven D'Aprano wrote:

> On Tue, 2 Jun 2015 09:40 pm, Rustom Mody wrote:
>
> > 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:
> [...]
> >> > *** 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'
>
> The OP says "THE [emphasis added] instance of class type" -- type has more
> than one instance.
>
>

Ok

> > In particular the issubclass relation is transitive
> > Whereas the isinstance is not
>
> Why is that relevant?

One way of construing the emphasized plural was what I pointed out as not the case
?x ? isinstance(x,t)
-- true or t = object but not t = type

Reply | Threaded
Open this post in threaded view
|

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

Terry Reedy
In reply to this post by Eddilbert Macharia
On 6/2/2015 6:36 AM, Eddilbert Macharia wrote:

> you guys are just confusing me, you are going in loops,

Ignore the troll who is trying to confuse you by slandering the rest of
us.  I have been using python for 18 years, I believe. Current Python
has a loop at the core

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

For using python, you hardly need to know this. (It obviously was not
true before 'object' was added in 2.2.)  The interpreter creates this
loop on startup with code similar to the following, except that it does
so with classes rather than lists.

 >>> lob = []
 >>> l0 = []
 >>> l1 = [l0]
 >>> l0.append(l1)
 >>> l0 in l1
True
 >>> l1 in l0
True

 > and still i have understood ,what makes everything in python an object.

Guido's decision to make python be that way.

--
Terry Jan Reedy


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 BartC-3
On Tue, 2 Jun 2015 10:49 pm, BartC wrote:

> On 02/06/2015 12:27, Steven D'Aprano wrote:
>
>> "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.
>
> The C Standard has hundreds of references to 'object'.

Are any of them objects in the sense of object oriented programming?

I'm pretty sure the answer to that is No. C is widely agreed to *not* be an
object oriented language, although obviously you can construct an OOP
system in C.

It is difficult to give a single, unconditional definition of "object" in
the object-oriented programming sense, because there are many subtle
variations. We can consume many hours in fruitless debates over an exact
formal definition of "object" in the sense of OOP, but I don't think that
is productive. But I think this should cover most of the common cases:


* An object-oriented programming language is one which provides objects
  as a native data type;

* objects are structured entities which combine:

  - behaviour (methods)
  - state (data, value)
  - and identity (unique existence);

* the structure and behaviour of the object is inherited from a
  class (blueprint or template), or a prototype (another object).


The important thing is that the language provides these as ready-to-use
features, complete with syntax and support from the compiler/interpreter. I
could write OOP-style code in C, or even assembly language, but only by
writing my own framework, then taking care to only write code within the
boundaries of that framework. Hence, C is not OOP: objects aren't built-in
to C, but have to be added.


> C objects are also linked to a type but it doesn't need to be explicit
> /in the run-time data/ because it's a static language. The compiler
> knows all the types because there are explicit annotations in the source
> code.

OOP can exist in both statically typed languages (such as Java, C++,
Objective C) and dynamically typed languages (such as Python, Javascript,
Ruby).


>> 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".
>
> In a dynamically typed language such as Python, you need to be able to
> deal with values consistently whatever their type, simply because you
> can't tell what the types are from source code. (Not without a lot of
> work which Python doesn't attempt, although RPython might do so.) Example:
>
>   print (a)
>
> a might be the int 42, or a it might be a million-element list. So both
> are wrapped up as 'objects'.

Again, this is not relevant. Javascript is dynamically typed, but some
values are machine primitives and other values are objects. The interpreter
keeps track of this at runtime.

Java is similar, except it keeps track if the difference between boxed and
unboxed types at compile time.


> Java is statically typed which makes it possible to treat instance
> variables differently without needing to examine their types at runtime.
> If you define 'object' in a certain way (eg. as boxed, tagged data),
> then it follows that some values don't need to be objects.

I'm not sure what point you are trying to make here.



--
Steven


Reply | Threaded
Open this post in threaded view
|

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

BartC-3
On 02/06/2015 18:00, Steven D'Aprano wrote:
> On Tue, 2 Jun 2015 10:49 pm, BartC wrote:
>
>> On 02/06/2015 12:27, Steven D'Aprano wrote:

>>> 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".
>>
>> In a dynamically typed language such as Python, you need to be able to
>> deal with values consistently whatever their type, simply because you
>> can't tell what the types are from source code. (Not without a lot of
>> work which Python doesn't attempt, although RPython might do so.) Example:
>>
>>    print (a)
>>
>> a might be the int 42, or a it might be a million-element list. So both
>> are wrapped up as 'objects'.
>
> Again, this is not relevant. Javascript is dynamically typed, but some
> values are machine primitives and other values are objects. The interpreter
> keeps track of this at runtime.

Javascript primitives include Number and String.

What does Python allow to be done with its Number (int, etc) and String
types that can't be done with their Javascript counterparts, that makes
/them/ objects?

--
Bartc

Reply | Threaded
Open this post in threaded view
|

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

random832@fastmail.us


On Tue, Jun 2, 2015, at 13:59, BartC wrote:

> On 02/06/2015 18:00, Steven D'Aprano wrote:
> > Again, this is not relevant. Javascript is dynamically typed, but some
> > values are machine primitives and other values are objects. The interpreter
> > keeps track of this at runtime.
>
> Javascript primitives include Number and String.
>
> What does Python allow to be done with its Number (int, etc) and String
> types that can't be done with their Javascript counterparts, that makes
> /them/ objects?

That's not really a fair question, because the Javascript object model
is so different from the Python one. The point is that they are handled
_the same_ as all other objects, not that they have some specific
capability.

Reply | Threaded
Open this post in threaded view
|

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

Jon Ribbens-5
In reply to this post by BartC-3
On 2015-06-02, BartC <bc at freeuk.com> wrote:

> On 02/06/2015 18:00, Steven D'Aprano wrote:
>> Again, this is not relevant. Javascript is dynamically typed, but some
>> values are machine primitives and other values are objects. The interpreter
>> keeps track of this at runtime.
>
> Javascript primitives include Number and String.
>
> What does Python allow to be done with its Number (int, etc) and String
> types that can't be done with their Javascript counterparts, that makes
> /them/ objects?

The fact that they are, er, objects? They are instances of classes,
they have methods that you can call, you can create subclasses, etc?

Reply | Threaded
Open this post in threaded view
|

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

Ned Batchelder
In reply to this post by BartC-3
On Tuesday, June 2, 2015 at 1:59:37 PM UTC-4, BartC wrote:

> On 02/06/2015 18:00, Steven D'Aprano wrote:
> > On Tue, 2 Jun 2015 10:49 pm, BartC wrote:
> >
> >> On 02/06/2015 12:27, Steven D'Aprano wrote:
>
> >>> 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".
> >>
> >> In a dynamically typed language such as Python, you need to be able to
> >> deal with values consistently whatever their type, simply because you
> >> can't tell what the types are from source code. (Not without a lot of
> >> work which Python doesn't attempt, although RPython might do so.) Example:
> >>
> >>    print (a)
> >>
> >> a might be the int 42, or a it might be a million-element list. So both
> >> are wrapped up as 'objects'.
> >
> > Again, this is not relevant. Javascript is dynamically typed, but some
> > values are machine primitives and other values are objects. The interpreter
> > keeps track of this at runtime.
>
> Javascript primitives include Number and String.
>
> What does Python allow to be done with its Number (int, etc) and String
> types that can't be done with their Javascript counterparts, that makes
> /them/ objects?

They have methods (not many, but a few):

>>> i, f = 1000001, 2.5
>>> i.bit_length()
20
>>> i.to_bytes(6, "big")
b'\x00\x00\x00\x0fBA'
>>> f.as_integer_ratio()
(5, 2)
>>> f.hex()
'0x1.4000000000000p+1'

--Ned.

>
> --
> Bartc


Reply | Threaded
Open this post in threaded view
|

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

Jon Ribbens-5
In reply to this post by BartC-3
On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:
> It doesn't really do anything.  No one uses integers as objects.
> (Any dissenters?)

Yes. *Everyone* uses integers as objects. Containers such as
lists and dictionaries and tuples etc contain objects. If
integers weren't objects then you wouldn't be able to put them
in containers (and you'd end up with Java).

Reply | Threaded
Open this post in threaded view
|

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

Jon Ribbens-5
On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:

> On Tuesday, June 2, 2015 at 1:49:03 PM UTC-5, Jon Ribbens wrote:
>> On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:
>> > It doesn't really do anything.  No one uses integers as objects.
>> > (Any dissenters?)
>>
>> Yes. *Everyone* uses integers as objects. Containers such as
>> lists and dictionaries and tuples etc contain objects. If
>> integers weren't objects then you wouldn't be able to put them
>> in containers (and you'd end up with Java).
>
> Sorry.  I meant "object" in the sense of OOP:  something you might
> extend or make a derived class with.

I'm not sure you get to define which properties of objects you want
not to count.

> Your last claim, must not be true because integers were able to be
> placed in objects before the type/class unification with v2.6, I
> believe.

Unless I'm misremembering, before that they were still objects,
just not quite the same kind of objects as pure-Python ones.

Reply | Threaded
Open this post in threaded view
|

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

Ian Kelly-2
In reply to this post by Ned Batchelder
On Tue, Jun 2, 2015 at 12:10 PM, Ned Batchelder <ned at nedbatchelder.com> wrote:

> On Tuesday, June 2, 2015 at 1:59:37 PM UTC-4, BartC wrote:
>> Javascript primitives include Number and String.
>>
>> What does Python allow to be done with its Number (int, etc) and String
>> types that can't be done with their Javascript counterparts, that makes
>> /them/ objects?
>
> They have methods (not many, but a few):
>
>>>> i, f = 1000001, 2.5
>>>> i.bit_length()
> 20
>>>> i.to_bytes(6, "big")
> b'\x00\x00\x00\x0fBA'
>>>> f.as_integer_ratio()
> (5, 2)
>>>> f.hex()
> '0x1.4000000000000p+1'

To add a wrinkle to this discussion, Javascript numbers also have methods:

js> (24).toExponential(3)
"2.400e+1"

I believe this is accomplished by implicitly boxing the number in the
Number class when a method or property is accessed. This can be seen
with:

js> (24).toSource()
"(new Number(24))"

Note that "24" and "new Number(24)" are not equivalent.

js> 24 === 24
true
js> 24 === new Number(24)
false
js> typeof(24)
"number"
js> typeof(new Number(24))
"object"

But this is a bit of an implementation detail. So what distinguishes
Javascript primitives from objects? Steven listed "identity" as a
third property of objects upthread; that seems applicable here.

Reply | Threaded
Open this post in threaded view
|

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

Ian Kelly-2
In reply to this post by Jon Ribbens-5
On Tue, Jun 2, 2015 at 12:47 PM, Jon Ribbens
<jon+usenet at unequivocal.co.uk> wrote:
> On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:
>> It doesn't really do anything.  No one uses integers as objects.
>> (Any dissenters?)
>
> Yes. *Everyone* uses integers as objects. Containers such as
> lists and dictionaries and tuples etc contain objects. If
> integers weren't objects then you wouldn't be able to put them
> in containers (and you'd end up with Java).

Javascript has no problem putting primitives into containers.

js> var arr = [0, 'test', new Object()];
js> typeof arr[0]
"number"
js> typeof arr[1]
"string"
js> typeof arr[2]
"object"

Reply | Threaded
Open this post in threaded view
|

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

Ian Kelly-2
In reply to this post by Jon Ribbens-5
On Tue, Jun 2, 2015 at 1:31 PM, Jon Ribbens
<jon+usenet at unequivocal.co.uk> wrote:

> On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:
>> On Tuesday, June 2, 2015 at 1:49:03 PM UTC-5, Jon Ribbens wrote:
>>> On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:
>>> > It doesn't really do anything.  No one uses integers as objects.
>>> > (Any dissenters?)
>>>
>>> Yes. *Everyone* uses integers as objects. Containers such as
>>> lists and dictionaries and tuples etc contain objects. If
>>> integers weren't objects then you wouldn't be able to put them
>>> in containers (and you'd end up with Java).
>>
>> Sorry.  I meant "object" in the sense of OOP:  something you might
>> extend or make a derived class with.
>
> I'm not sure you get to define which properties of objects you want
> not to count.

Accepting for the sake of argument that "something to be subclassed"
is a reasonable definition of object, it should be pointed out that
anybody who works with bools in Python is using integers as objects.

The "Super Considered Harmful" essay also has a couple of examples of
subclasses of int, and even just googling "python subclass int"
demonstrates that there is plenty of interest in the subject.

Reply | Threaded
Open this post in threaded view
|

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

Grant Edwards-7
In reply to this post by Jon Ribbens-5
On 2015-06-02, Ian Kelly <ian.g.kelly at gmail.com> wrote:

>>> Sorry.  I meant "object" in the sense of OOP:  something you might
>>> extend or make a derived class with.
>>
>> I'm not sure you get to define which properties of objects you want
>> not to count.
>
> Accepting for the sake of argument that "something to be subclassed"
> is a reasonable definition of object,

Huh?  You can't subclass an object.  You can subclass a Class.

--
Grant Edwards               grant.b.edwards        Yow! I want to so HAPPY,
                                  at               the VEINS in my neck STAND
                              gmail.com            OUT!!

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 Ian Kelly-2
On 02/06/2015 20:50, Ian Kelly wrote:

> On Tue, Jun 2, 2015 at 1:31 PM, Jon Ribbens
> <jon+usenet at unequivocal.co.uk> wrote:
>> On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:
>>> On Tuesday, June 2, 2015 at 1:49:03 PM UTC-5, Jon Ribbens wrote:
>>>> On 2015-06-02, Dr. Bigcock <dreamingforward at gmail.com> wrote:
>>>>> It doesn't really do anything.  No one uses integers as objects.
>>>>> (Any dissenters?)
>>>>
>>>> Yes. *Everyone* uses integers as objects. Containers such as
>>>> lists and dictionaries and tuples etc contain objects. If
>>>> integers weren't objects then you wouldn't be able to put them
>>>> in containers (and you'd end up with Java).
>>>
>>> Sorry.  I meant "object" in the sense of OOP:  something you might
>>> extend or make a derived class with.
>>
>> I'm not sure you get to define which properties of objects you want
>> not to count.
>
> Accepting for the sake of argument that "something to be subclassed"
> is a reasonable definition of object, it should be pointed out that
> anybody who works with bools in Python is using integers as objects.
>
> The "Super Considered Harmful" essay also has a couple of examples of
> subclasses of int, and even just googling "python subclass int"
> demonstrates that there is plenty of interest in the subject.
>

The classic response to "Super Considered Harmful" for those who may be
interested is
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ and
recently https://www.youtube.com/watch?v=EiOglTERPEo

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

Marko Rauhamaa
In reply to this post by Grant Edwards-7
Grant Edwards <invalid at invalid.invalid>:

> On 2015-06-02, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> Accepting for the sake of argument that "something to be subclassed"
>> is a reasonable definition of object,
>
> Huh?  You can't subclass an object.  You can subclass a Class.

More to the point: you don't need classes for objects -- even in the
deepest OOP sense.

In Python, classes are little more than constructor functions.


Marko

Reply | Threaded
Open this post in threaded view
|

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

Ian Kelly-2
In reply to this post by Mark Lawrence
On Tue, Jun 2, 2015 at 3:47 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> The classic response to "Super Considered Harmful" for those who may be
> interested is
> https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ and
> recently https://www.youtube.com/watch?v=EiOglTERPEo

I feel slightly cheated. In the video he promises to show how to do
dependency injection using super, but in both of the examples given,
every instance of "super()" could simply be replaced with "self" and
the result would be the same. That's just taking advantage of the MRO,
not super.

12345