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

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

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

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

Contents

  Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-05-31 07:34 -0700
    Re: Everything is an object in python - object class and type class Marco Buttu <marco.buttu@gmail.com> - 2015-05-31 17:13 +0200
    Re: Everything is an object in python - object class and type class Terry Reedy <tjreedy@udel.edu> - 2015-05-31 11:37 -0400
    Re: Everything is an object in python - object class and type class Steven D'Aprano <steve@pearwood.info> - 2015-06-01 04:00 +1000
      Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-01 10:35 -0700
    Re: Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-05-31 17:29 -0700
      Re: Everything is an object in python - object class and type class Steven D'Aprano <steve@pearwood.info> - 2015-06-01 14:09 +1000
    Re: Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-05-31 20:09 -0700
      Re: Everything is an object in python - object class and type class Steven D'Aprano <steve@pearwood.info> - 2015-06-01 14:24 +1000
    Re: Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-06-01 05:03 -0700
      Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-01 23:59 +0100
        Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-02 11:45 +0100
          Re: Everything is an object in python - object class and type class Rustom Mody <rustompmody@gmail.com> - 2015-06-02 04:16 -0700
        Re: Everything is an object in python - object class and type class Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-02 09:09 -0600
      Re: Everything is an object in python - object class and type class TheDoctor <dreamingforward@gmail.com> - 2015-06-01 17:24 -0700
        Re: Everything is an object in python - object class and type class Chris Angelico <rosuav@gmail.com> - 2015-06-02 10:32 +1000
          Re: Everything is an object in python - object class and type class TheDoctor <dreamingforward@gmail.com> - 2015-06-01 18:02 -0700
            Re: Everything is an object in python - object class and type class Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-02 16:30 +1000
          Re: Everything is an object in python - object class and type class TheDoctor <dreamingforward@gmail.com> - 2015-06-01 18:15 -0700
            Re: Everything is an object in python - object class and type class Chris Angelico <rosuav@gmail.com> - 2015-06-02 11:30 +1000
            Re: Everything is an object in python - object class and type class random832@fastmail.us - 2015-06-02 00:13 -0400
            Re: Everything is an object in python - object class and type class Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-02 16:23 +1000
        Re: Everything is an object in python - object class and type class Rustom Mody <rustompmody@gmail.com> - 2015-06-01 20:15 -0700
          Re: Everything is an object in python - object class and type class Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-02 04:46 +0100
          Re: Everything is an object in python - object class and type class TheDoctor <dreamingforward@gmail.com> - 2015-06-01 21:47 -0700
            Re: Everything is an object in python - object class and type class Rustom Mody <rustompmody@gmail.com> - 2015-06-01 22:01 -0700
              Religion [was Re: Everything is an object in python - object class and type class] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-02 16:04 +1000
                Re: Religion [was Re: Everything is an object in python - object class and type class] Rustom Mody <rustompmody@gmail.com> - 2015-06-01 23:17 -0700
                Re: Religion [was Re: Everything is an object in python - object class and type class] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-02 07:20 +0100
        Re: Everything is an object in python - object class and type class random832@fastmail.us - 2015-06-02 00:08 -0400
          Re: Everything is an object in python - object class and type class TheDoctor <dreamingforward@gmail.com> - 2015-06-01 21:54 -0700
        Re: Everything is an object in python - object class and type class Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-02 17:12 +1000
          Re: Everything is an object in python - object class and type class Rustom Mody <rustompmody@gmail.com> - 2015-06-02 00:44 -0700
            Re: Everything is an object in python - object class and type class Chris Angelico <rosuav@gmail.com> - 2015-06-02 18:37 +1000
              Re: Everything is an object in python - object class and type class Rustom Mody <rustompmody@gmail.com> - 2015-06-02 02:18 -0700
              Re: Everything is an object in python - object class and type class Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 12:23 +0300
    Re: Everything is an object in python - object class and type class vern.muhr@gmail.com - 2015-06-01 14:12 -0700
    Re: Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-06-02 03:36 -0700
      Re: Everything is an object in python - object class and type class Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-02 12:11 +0100
      Re: Everything is an object in python - object class and type class Steven D'Aprano <steve@pearwood.info> - 2015-06-02 21:27 +1000
        Re: Everything is an object in python - object class and type class Rustom Mody <rustompmody@gmail.com> - 2015-06-02 04:40 -0700
          Re: Everything is an object in python - object class and type class Steven D'Aprano <steve@pearwood.info> - 2015-06-03 01:08 +1000
            Re: Everything is an object in python - object class and type class Rustom Mody <rustompmody@gmail.com> - 2015-06-02 09:14 -0700
        Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-02 13:49 +0100
          Re: Everything is an object in python - object class and type class Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 16:13 +0300
          Re: Everything is an object in python - object class and type class Steven D'Aprano <steve@pearwood.info> - 2015-06-03 03:00 +1000
            Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-02 18:59 +0100
              Re: Everything is an object in python - object class and type class random832@fastmail.us - 2015-06-02 14:07 -0400
              Re: Everything is an object in python - object class and type class Ned Batchelder <ned@nedbatchelder.com> - 2015-06-02 11:10 -0700
                Re: Everything is an object in python - object class and type class Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-02 13:36 -0600
              Re: Everything is an object in python - object class and type class Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-02 18:10 +0000
              Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-02 11:22 -0700
                Re: Everything is an object in python - object class and type class Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-02 18:47 +0000
                  Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-02 12:00 -0700
                    Re: Everything is an object in python - object class and type class Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-06-02 19:31 +0000
                      Re: Everything is an object in python - object class and type class Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-02 13:50 -0600
                        Re: Everything is an object in python - object class and type class Grant Edwards <invalid@invalid.invalid> - 2015-06-02 21:19 +0000
                          Re: Everything is an object in python - object class and type class Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 01:33 +0300
                            Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-02 15:49 -0700
                              Re: Everything is an object in python - object class and type class Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-03 18:13 +1000
                                Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-03 21:38 -0700
                            Re: Everything is an object in python - object class and type class Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-03 18:24 +1000
                              Re: Everything is an object in python - object class and type class Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 11:57 +0300
                                Re: Everything is an object in python - object class and type class Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-03 07:57 -0600
                                Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-03 21:42 -0700
                      Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-02 12:58 -0700
                      Re: Everything is an object in python - object class and type class Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-02 22:47 +0100
                      Re: Everything is an object in python - object class and type class Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-02 18:49 -0600
                      Re: Everything is an object in python - object class and type class Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-03 18:32 +1000
                  Re: Everything is an object in python - object class and type class Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-02 13:37 -0600
              Re: Everything is an object in python - object class and type class Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-03 18:08 +1000
            Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-02 11:00 -0700
        Re: Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-06-02 21:16 -0700
          Re: Everything is an object in python - object class and type class Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-03 06:23 +0100
          Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-03 11:20 +0100
            Re: Everything is an object in python - object class and type class Chris Angelico <rosuav@gmail.com> - 2015-06-03 20:38 +1000
              Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-03 12:08 +0100
                Re: Everything is an object in python - object class and type class Marko Rauhamaa <marko@pacujo.net> - 2015-06-03 15:08 +0300
                  Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-03 17:00 +0100
                    Re: Everything is an object in python - object class and type class Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-03 17:29 +0100
                      Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-03 19:59 +0100
                        Re: Everything is an object in python - object class and type class Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-03 21:58 +0100
                          Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-03 22:33 +0100
                            Re: Everything is an object in python - object class and type class Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-03 22:49 +0100
                              Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-04 00:04 +0100
                                Re: Everything is an object in python - object class and type class Laura Creighton <lac@openend.se> - 2015-06-04 12:06 +0200
                                  Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-04 13:01 +0100
                                    Re: Everything is an object in python - object class and type class Laura Creighton <lac@openend.se> - 2015-06-04 15:39 +0200
                          Re: Everything is an object in python - object class and type class "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-03 21:50 -0700
                            Re: Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-06-03 22:43 -0700
                    Re: Everything is an object in python - object class and type class Michael Torrie <torriem@gmail.com> - 2015-06-03 10:36 -0600
                      Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-03 18:26 +0100
                        Re: Everything is an object in python - object class and type class Steven D'Aprano <steve@pearwood.info> - 2015-06-05 00:11 +1000
                    Re: Everything is an object in python - object class and type class Terry Reedy <tjreedy@udel.edu> - 2015-06-03 13:17 -0400
                Re: Everything is an object in python - object class and type class Chris Angelico <rosuav@gmail.com> - 2015-06-03 22:19 +1000
                Re: Everything is an object in python - object class and type class Marco Buttu <marco.buttu@gmail.com> - 2015-06-03 14:10 +0200
            Re: Everything is an object in python - object class and type class BartC <bc@freeuk.com> - 2015-06-03 12:13 +0100
            Re: Everything is an object in python - object class and type class Terry Reedy <tjreedy@udel.edu> - 2015-06-03 13:05 -0400
      Re: Everything is an object in python - object class and type class Terry Reedy <tjreedy@udel.edu> - 2015-06-02 12:23 -0400
    Re: Everything is an object in python - object class and type class Eddilbert Macharia <edd.cowan@gmail.com> - 2015-06-03 06:17 -0700

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

#92023

On Wednesday, June 3, 2015 at 3:13:45 AM UTC-5, Steven D'Aprano wrote:
> On Wednesday 03 June 2015 08:49, Dr. Bigcock wrote:
> 
> > You need classes for objects.  Anything else, and you're confusing
> > yourself.
> 
> 
> Not quite.
> 
> https://en.wikipedia.org/wiki/Prototype-based_programming

Yes, but those are classes too, just with another name.  This is.... not a semantic fungi, but a syntactic one.

--m

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

#91930

On Wednesday 03 June 2015 08:33, Marko Rauhamaa wrote:

> Grant Edwards <invalid@invalid.invalid>:
> 
>> On 2015-06-02, Ian Kelly <ian.g.kelly@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.

That part is true.

> In Python, classes are little more than constructor functions.

But that's not.

Classes give you an inheritance hierarchy. They also hold shared state, and 
behaviour for the instances.



-- 
Steve

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

#91932

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> On Wednesday 03 June 2015 08:33, Marko Rauhamaa wrote:
>> In Python, classes are little more than constructor functions.
>
> [...]
>
> Classes give you an inheritance hierarchy.

That's encapsulated in the constructor. From the class user's point of
view, it doesn't matter if the object derives its behavior through
inheritance or through reimplementation. From the class implementor's
point of view, inheritance is syntactic sugar.

> They also hold shared state, and behaviour for the instances.

That's the "little more" I was referring to. It is Python esoterics
that can safely be ignored.


Marko

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

#91965

On Wed, Jun 3, 2015 at 2:57 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> On Wednesday 03 June 2015 08:33, Marko Rauhamaa wrote:
>>> In Python, classes are little more than constructor functions.
>>
>> [...]
>>
>> Classes give you an inheritance hierarchy.
>
> That's encapsulated in the constructor.

Not entirely true.

>>> class A:
...   def say_hi(self):
...     print("Hello!")
...
>>> class B:
...   def say_hi(self):
...     print("G'day!")
...
>>> obj = A()
>>> obj.say_hi()
Hello!
>>> obj.__class__ = B
>>> obj.say_hi()
G'day!

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

#92024

On Wednesday, June 3, 2015 at 3:57:43 AM UTC-5, Marko Rauhamaa wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
> > On Wednesday 03 June 2015 08:33, Marko Rauhamaa wrote:
> >> In Python, classes are little more than constructor functions.
> >
> > [...]
> >
> > Classes give you an inheritance hierarchy.
> 
> That's encapsulated in the constructor. From the class user's point of
> view, it doesn't matter if the object derives its behavior through
> inheritance or through reimplementation. From the class implementor's
> point of view, inheritance is syntactic sugar.

No, it's not, inheritance tells you how to relate to other aspects of the object (as an abstraction intended by the programmer).  For example, when you want to delegate using super, it informs you how you want to use that.

mark

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

#91889

On Tuesday, June 2, 2015 at 2:32:46 PM UTC-5, Jon Ribbens wrote:
> On 2015-06-02, Dr. Bigcock <dreamingforward@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@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.

I'm not really defining that.  That idea goes back to the beginning of the OOP paradigm.  But, hey, why not just define it here: 

An object (as it refers to the paradigm of object-orientation, designated primarily for the purpose of re-useable code) embodies these traits:

1. Encapsulation (keeps data and operations attached to a single NAME, becoming the "object")
2. Inheritance (forming a new relationship to the object, either extending it or refining it).

Without these two, it isn't OOP.  These two are both necessary and sufficient to create an OOP langauge.  

But hey, would love to see if we can settle this old debate...

Mark

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

#91905

On 02/06/2015 20:50, Ian Kelly wrote:
> On Tue, Jun 2, 2015 at 1:31 PM, Jon Ribbens
> <jon+usenet@unequivocal.co.uk> wrote:
>> On 2015-06-02, Dr. Bigcock <dreamingforward@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@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

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

#91915

On Tue, Jun 2, 2015 at 3:47 PM, Mark Lawrence <breamoreboy@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.

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

#91931

On Wednesday 03 June 2015 05:31, Jon Ribbens wrote:

> On 2015-06-02, Dr. Bigcock <dreamingforward@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@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.

Correct. It was version 2.2, not 2.6, that unified built-in types with 
classes. Prior to that, Python had two distinct kinds of object, with 
separate hierarchies:


Types  (builtins, defined in C)
 +-- int
 +-- dict
 +-- str
 +-- list

Classes  (custom-made in Python using the class keyword)
 +-- Foo
 +-- Bar
      +-- FooBar
      +-  FooBarBaz


You could only subclass classes, not types. But *both* were kinds of 
objects. They were just separate, with slightly different characteristics.

Starting with 2.2, the old-style classic classes still existed, for 
backwards compatibility, but Python introduced a single base-class for the 
built-in types, called it "object", and enabled subclassing from pure-Python 
code:


Unified types/classes ("new-style classes")
 +-- object
     +-- int
         +-- MyInteger
     +-- dict
     +-- str
     +-- list
         +-- MyList
     +-- Spam

Classic Classes ("old-style classes")
[unchanged from above]


Finally, in Python 3, the classic classes were removed, and Python now has a 
single unified type/class hierarchy, with "object" at the root.


But regardless of whether Python had a single type hierarchy or two separate 
hierarchies, all values in Python were still implemented as objects.


-- 
Steve

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

#91887

On Tue, Jun 2, 2015 at 12:47 PM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2015-06-02, Dr. Bigcock <dreamingforward@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"

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

#91927

On Wednesday 03 June 2015 03:59, 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?

That's a good question, and I'm not sure whether or not the answer is 
"nothing, it's just an implementation detail".

I don't *think* it is an implementation detail, but I don't know enough 
about Javascript to be sure. I can see that you can include Numbers in an 
object without explicitly boxing them:

js> var foo = 23;
js> typeof foo;  
number
js> var bar = {1: foo};
js> typeof bar[1];
number


I can also see that you can explicitly box numbers inside objects:

js> var a = 42;
js> var b = new Number(42);
js> a == b;
true
js> a === b;
false
js> typeof a;
number
js> typeof b;
object


But I don't know enough to tell the practical differences between them.



-- 
Steve

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

#91871

On Tuesday, June 2, 2015 at 12:01:03 PM UTC-5, Steven D'Aprano wrote:
> 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.

The only relevant question here is:  how would you go about laying out memory to distinguish objects (or even structs) from mere data words?  Does the compiler indicate an object by a flag in high-order bit? 

--m

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

#91919

On Tuesday, June 2, 2015 at 2:27:31 PM UTC+3, 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.
> 
> 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.

Sadly yes i have worked with java, and that is what is causing me so much grief.In java objects are instance of a class.pretty simple.

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

I think then in python object and instance of a class are entirely different things.

in OOP and python - object is a representation of a real thing, or a concept .e.g a person,number and the concept of classes- which is the concept of create/representing other objects using a programming language to the machine.

class - This is what is used to create/represent objects in the machine using a programming language

class instance - This is the output of the classes this is a representation of an object.


> -- 
> Steven

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

#91920

On 03/06/2015 05:16, Eddilbert Macharia wrote:
>
> Sadly yes i have worked with java, and that is what is causing me so much grief.In java objects are instance of a class.pretty simple.
>

You might like to read 
http://dirtsimple.org/2004/12/python-is-not-java.html and 
http://dirtsimple.org/2004/12/java-is-not-python-either.html

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

Mark Lawrence

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

#91939

On 03/06/2015 05:16, Eddilbert Macharia wrote:
> On Tuesday, June 2, 2015 at 2:27:31 PM UTC+3, Steven D'Aprano wrote:

>> Eddilbert, have you programmed in any other languages? It would help you
>> understand if you have.
>
> Sadly yes i have worked with java, and that is what is causing me so much grief.In java objects are instance of a class.pretty simple.

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

> I think then in python object and instance of a class are entirely different things.
>
> in OOP and python - object is a representation of a real thing, or a concept .e.g a person,number and the concept of classes- which is the concept of create/representing other objects using a programming language to the machine.
>
> class - This is what is used to create/represent objects in the machine using a programming language
>
> class instance - This is the output of the classes this is a representation of an object.

I have a lot of trouble with this stuff too, as my ideas are decidedly 
old-fashioned. (Also I'm developing a language with some OO aspects 
without ever having used OO!)

But, it is mostly just jargon. If you go back to using 'variable' and 
'type', then it becomes a bit easier:

* A variable is an instance of some type.

And, that's pretty much it!

However, modern languages such as Python add a few more twists. So, if a 
static, compiled language, say, had these kinds of things:

- Module
- Record definition
- Enum type
- Label (for goto)
- Function
- Type

which are normally entities that only the compiler are concerned with, 
then these can now also be values that can be stored in variables! (One 
or two such languages might allow pointers to Functions or Labels, but 
that's about it.)

Exactly what it is about a Module, Record or Function that is stored in 
the variable is an implementation detail. The important thing is that 
you can use such as variable at runtime in the same way you might do at 
compile-time.

Python of course would subsume concepts such as Records or Enums into a 
class, as it seems to like to unify what it considers to be untidy, 
separate aspects of a language. Some of us however need things separated 
out again in order to understand them!

(This is a set of codes I'm using in a current compiler project, for a 
new language. Each denotes a separate kind of identifier in the input 
source:

	nullid = 0
	programid = 1
	moduleid = 2
	extmoduleid = 3
	classid = 4
	procid = 5
	staticid = 6
	constid = 7
	fieldid = 8
	genfieldid = 9
	enumid = 10
	paramid = 11
	frameid = 12
	varid = 13      # ?
	labelid = 14
	blockid = 15
	attribid = 16
	aliasid = 17

The language requires that each identifier is resolved at compile-time 
to one of the above. This makes it rather less dynamic than Python, 
where the bytecode compiler, as far as I know, only resolves a name as 
either global or local (and perhaps attribute, but I'm not an expert on 
its workings).

(The 'varid' code was for a unresolved top-level name, which I will 
probably remove as that was added when I'd intended to emulate Python 
more. But that was too much work (and too many speed-ups were no longer 
trivial). Some codes such as 'nullid' and 'programid' are only used 
internally.

'genfield' is a field (attribute) that can't be resolved, but the 
possibilities have been reduced to a small, finite set which  is 
resolved at load-time (in Python, the attribute could be anything, and 
you don't even know at runtime what it might be until you actually use 
the attribute.)

In this list, then 'static', 'frame', and 'param' denote what I'd call 
variables. A variable, at runtime, contains a value of a certain type 
(another list of codes). One of those types however is a Symbol: just a 
reference (a symbol table index) to a resolved name in the source code.

Just a different approach to things. But since the ultimate aim is to be 
able to write programs, not so different.)

-- 
Bartc

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

#91941

On Wed, Jun 3, 2015 at 8:20 PM, BartC <bc@freeuk.com> wrote:
> I have a lot of trouble with this stuff too, as my ideas are decidedly
> old-fashioned. (Also I'm developing a language with some OO aspects without
> ever having used OO!)
>
> But, it is mostly just jargon. If you go back to using 'variable' and
> 'type', then it becomes a bit easier:
>
> * A variable is an instance of some type.
>
> And, that's pretty much it!

If I have a list called "stuff" with three elements in it, is
"stuff[1]" a variable? What if I return that list from a function
called get_stuff()? Is get_stuff()[1] a variable? Because in Python,
get_stuff()[1] is certainly going to be an object.

ChrisA

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

#91943

On 03/06/2015 11:38, Chris Angelico wrote:
> On Wed, Jun 3, 2015 at 8:20 PM, BartC <bc@freeuk.com> wrote:
>> I have a lot of trouble with this stuff too, as my ideas are decidedly
>> old-fashioned. (Also I'm developing a language with some OO aspects without
>> ever having used OO!)
>>
>> But, it is mostly just jargon. If you go back to using 'variable' and
>> 'type', then it becomes a bit easier:
>>
>> * A variable is an instance of some type.
>>
>> And, that's pretty much it!
>
> If I have a list called "stuff" with three elements in it, is
> "stuff[1]" a variable? What if I return that list from a function
> called get_stuff()? Is get_stuff()[1] a variable? Because in Python,
> get_stuff()[1] is certainly going to be an object.

Come on, we're trying to keep this simple.

To 'variable' and 'type', you might need to add 'value' to make it more 
complete. An old-fashioned program will be moving values around and 
constructing new ones. Some of them will be loaded from variables, and 
some might end up being stored in variables.

(With the obligatory twist in Python that variable names are not 
directly attached to their values, but via a 'string'. I can introduce a 
new term for what /is/ actually stored /with/ the variable, as it's got 
to be something unless Python works by magic, but I don't want to do that.)

You might call such a value an 'object'. The trouble is, Python also 
uses 'object' to mean the base class of all classes. And it seems to use 
it in a more abstract sense as well to mean pretty much everything. 
While other languages, such as C, use object in yet another way.

Which is where the term breaks down as it no longer helps in 
understanding. It's become meaningless.

-- 
Bartc

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

#91946

BartC <bc@freeuk.com>:

> To 'variable' and 'type', you might need to add 'value' to make it more
> complete.

'Value' and 'object' are indeed synonymous as long as you keep in mind
that:

    >>> -12 == -12
    True
    >>> -12 is -12
    False

IOW, the literal expression -12 happens to construct a fresh
value/object each time CPython parses it.

> You might call such a value an 'object'. The trouble is, Python also
> uses 'object' to mean the base class of all classes.

'object' is the class of all objects just like 'int' is the class of all
integers. So no trouble at all.

> And it seems to use it in a more abstract sense as well to mean pretty
> much everything. While other languages, such as C, use object in yet
> another way.
>
> Which is where the term breaks down as it no longer helps in
> understanding. It's become meaningless.

Correct! Abstractions are generalizations of specifics. You can't
understand the generalizations before being bored with the specifics
first.


Marko

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

#91972

On 03/06/2015 13:08, Marko Rauhamaa wrote:
> BartC <bc@freeuk.com>:
>
>> To 'variable' and 'type', you might need to add 'value' to make it more
>> complete.
>
> 'Value' and 'object' are indeed synonymous as long as you keep in mind
> that:
>
>      >>> -12 == -12
>      True
>      >>> -12 is -12
>      False
>
> IOW, the literal expression -12 happens to construct a fresh
> value/object each time CPython parses it.

That's a different matter. However, you appear to be wrong.

print (-12 is -12)

gives True. As does ("abc" is "abc"). I assume constructions for 
immutable values will do the same (([10,20,30] is [10,20,30]) gives 
False because the constructs are mutable, although it's difficult to see 
how in that form).

(This is on 2.7, 3.1 and PyPy. On 3.4.3, (-12 is -12) gives False as you 
say, although (12 is 12) gives True, so not even Python can make up its 
mind how it's supposed to work!)

3.4.3:

print (-12 is -12)                                     => False
print (12 is 12)                                       => True
print (20000000000000000000 is 20000000000000000000)   => True

The others all give True in all cases. It seems that older Python 
versions have a purer object model.

-- 
Bartc

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

#91974

On 03/06/2015 17:00, BartC wrote:
> On 03/06/2015 13:08, Marko Rauhamaa wrote:
>> BartC <bc@freeuk.com>:
>>
>>> To 'variable' and 'type', you might need to add 'value' to make it more
>>> complete.
>>
>> 'Value' and 'object' are indeed synonymous as long as you keep in mind
>> that:
>>
>>      >>> -12 == -12
>>      True
>>      >>> -12 is -12
>>      False
>>
>> IOW, the literal expression -12 happens to construct a fresh
>> value/object each time CPython parses it.
>
> That's a different matter. However, you appear to be wrong.
>
> print (-12 is -12)
>
> gives True. As does ("abc" is "abc"). I assume constructions for
> immutable values will do the same (([10,20,30] is [10,20,30]) gives
> False because the constructs are mutable, although it's difficult to see
> how in that form).
>
> (This is on 2.7, 3.1 and PyPy. On 3.4.3, (-12 is -12) gives False as you
> say, although (12 is 12) gives True, so not even Python can make up its
> mind how it's supposed to work!)
>
> 3.4.3:
>
> print (-12 is -12)                                     => False
> print (12 is 12)                                       => True
> print (20000000000000000000 is 20000000000000000000)   => True
>
> The others all give True in all cases. It seems that older Python
> versions have a purer object model.
>

No, you don't understand how cPython does things.

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

Mark Lawrence

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

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

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

csiph-web