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

Started byEddilbert Macharia <edd.cowan@gmail.com>
First post2015-05-31 07:34 -0700
Last post2015-06-03 06:17 -0700
Articles 20 on this page of 100 — 20 participants

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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →


#91823

FromRustom Mody <rustompmody@gmail.com>
Date2015-06-02 04:40 -0700
Message-ID<1d07e9d4-8314-4b5a-8f98-4174b89370ee@googlegroups.com>
In reply to#91822
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

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


#91846

FromSteven D'Aprano <steve@pearwood.info>
Date2015-06-03 01:08 +1000
Message-ID<556dc6ea$0$13004$c3e8da3$5496439d@news.astraweb.com>
In reply to#91823
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

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


#91854

FromRustom Mody <rustompmody@gmail.com>
Date2015-06-02 09:14 -0700
Message-ID<9d580d9e-eda4-4441-a929-fd0275845561@googlegroups.com>
In reply to#91846
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

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


#91833

FromBartC <bc@freeuk.com>
Date2015-06-02 13:49 +0100
Message-ID<yDhbx.572527$oZ4.306159@fx38.am4>
In reply to#91822
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

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


#91836

FromMarko Rauhamaa <marko@pacujo.net>
Date2015-06-02 16:13 +0300
Message-ID<87siaa6yoc.fsf@elektro.pacujo.net>
In reply to#91833
BartC <bc@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

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


#91865

FromSteven D'Aprano <steve@pearwood.info>
Date2015-06-03 03:00 +1000
Message-ID<556de143$0$13009$c3e8da3$5496439d@news.astraweb.com>
In reply to#91833
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

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


#91870

FromBartC <bc@freeuk.com>
Date2015-06-02 18:59 +0100
Message-ID<%9mbx.608935$JH2.445461@fx11.am4>
In reply to#91865
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

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


#91873

Fromrandom832@fastmail.us
Date2015-06-02 14:07 -0400
Message-ID<mailman.73.1433268425.13271.python-list@python.org>
In reply to#91870

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.

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


#91876

FromNed Batchelder <ned@nedbatchelder.com>
Date2015-06-02 11:10 -0700
Message-ID<4d0ad8f5-d29f-442e-9374-5cda12153f88@googlegroups.com>
In reply to#91870
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

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


#91886

FromIan Kelly <ian.g.kelly@gmail.com>
Date2015-06-02 13:36 -0600
Message-ID<mailman.76.1433273826.13271.python-list@python.org>
In reply to#91876
On Tue, Jun 2, 2015 at 12:10 PM, Ned Batchelder <ned@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.

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


#91877

FromJon Ribbens <jon+usenet@unequivocal.co.uk>
Date2015-06-02 18:10 +0000
Message-ID<slrnmmrsf7.20b.jon+usenet@frosty.unequivocal.co.uk>
In reply to#91870
On 2015-06-02, BartC <bc@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?

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


#91880

From"Dr. Bigcock" <dreamingforward@gmail.com>
Date2015-06-02 11:22 -0700
Message-ID<d7dfabae-a252-476e-aeef-a76e29be202a@googlegroups.com>
In reply to#91870
On Tuesday, June 2, 2015 at 12:59:37 PM UTC-5, 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?

It doesn't really do anything.  No one uses integers as objects.  (Any dissenters?)  Python was trying to be too pure and it missed the practical aspect of the machine.  It's not it's fault.  It was an exploration of an abstract concept of "everything is an object".  

--m

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


#91882

FromJon Ribbens <jon+usenet@unequivocal.co.uk>
Date2015-06-02 18:47 +0000
Message-ID<slrnmmrukl.20b.jon+usenet@frosty.unequivocal.co.uk>
In reply to#91880
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).

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


#91883

From"Dr. Bigcock" <dreamingforward@gmail.com>
Date2015-06-02 12:00 -0700
Message-ID<914115ea-0f93-4929-b325-5b3f78f5d9f1@googlegroups.com>
In reply to#91882
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.

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.

--m

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


#91885

FromJon Ribbens <jon+usenet@unequivocal.co.uk>
Date2015-06-02 19:31 +0000
Message-ID<slrnmms16k.20b.jon+usenet@frosty.unequivocal.co.uk>
In reply to#91883
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.

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


#91888

FromIan Kelly <ian.g.kelly@gmail.com>
Date2015-06-02 13:50 -0600
Message-ID<mailman.78.1433274654.13271.python-list@python.org>
In reply to#91885
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.

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


#91897

FromGrant Edwards <invalid@invalid.invalid>
Date2015-06-02 21:19 +0000
Message-ID<mkl6l1$lle$1@reader1.panix.com>
In reply to#91888
On 2015-06-02, Ian Kelly <ian.g.kelly@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!!

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


#91909

FromMarko Rauhamaa <marko@pacujo.net>
Date2015-06-03 01:33 +0300
Message-ID<871tht7nc3.fsf@elektro.pacujo.net>
In reply to#91897
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.

In Python, classes are little more than constructor functions.


Marko

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


#91910

From"Dr. Bigcock" <dreamingforward@gmail.com>
Date2015-06-02 15:49 -0700
Message-ID<fb0716a8-6470-48fe-b82b-b1587a486e04@googlegroups.com>
In reply to#91909
On Tuesday, June 2, 2015 at 5:33:10 PM UTC-5, 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.

Gosh.  The "deepest sense"?  Would you stop wanging your chode?  Because you are deeply confusing LISP with OOP.

LISP has code and data grouped in parentheses, creating a lexical closure that stands on it's own.  But the objects in OOP are completely fscking different.  That's why in Hacking with the Tao (bless his holy name), there's a distinction between coding on vonNeumann machines and the theoretician's ultimate lambda.

You need classes for objects.  Anything else, and you're confusing yourself.   Int, for example, should not be a class.  Stop this glorification of trying to make Python a re-implementation of LISP.  There was a quote about that somewhere....

--m



 feel a lot like objects, but they're completely different beasts.  They feel like objects because they both enclose

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


#91928

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2015-06-03 18:13 +1000
Message-ID<556eb72f$0$12904$c3e8da3$5496439d@news.astraweb.com>
In reply to#91910
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




-- 
Steve

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


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

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


csiph-web