Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #91576 > unrolled thread
| Started by | Eddilbert Macharia <edd.cowan@gmail.com> |
|---|---|
| First post | 2015-05-31 07:34 -0700 |
| Last post | 2015-06-03 06:17 -0700 |
| Articles | 20 on this page of 100 — 20 participants |
Back to article view | Back to comp.lang.python
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 →
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-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]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-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]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-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]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-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]
| From | random832@fastmail.us |
|---|---|
| Date | 2015-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]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2015-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]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2015-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]
| From | "Dr. Bigcock" <dreamingforward@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2015-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]
| From | "Dr. Bigcock" <dreamingforward@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2015-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]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2015-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]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-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]
| From | "Dr. Bigcock" <dreamingforward@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-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