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

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

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

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


Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

Steven D'Aprano-11
In reply to this post by BartC-3
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


Reply | Threaded
Open this post in threaded view
|

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

Steven D'Aprano-11
In reply to this post by Marko Rauhamaa
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


Reply | Threaded
Open this post in threaded view
|

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

Steven D'Aprano-11
In reply to this post by Marko Rauhamaa
On Wednesday 03 June 2015 08:33, Marko Rauhamaa wrote:

> Grant Edwards <invalid at invalid.invalid>:
>
>> On 2015-06-02, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>>> Accepting for the sake of argument that "something to be subclassed"
>>> is a reasonable definition of object,
>>
>> Huh?  You can't subclass an object.  You can subclass a Class.
>
> More to the point: you don't need classes for objects -- even in the
> deepest OOP sense.

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


Reply | Threaded
Open this post in threaded view
|

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

Steven D'Aprano-11
In reply to this post by Jon Ribbens-5
On Wednesday 03 June 2015 05:31, Jon Ribbens wrote:

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


Reply | Threaded
Open this post in threaded view
|

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

Marko Rauhamaa
In reply to this post by Steven D'Aprano-11
Steven D'Aprano <steve+comp.lang.python at 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

Reply | Threaded
Open this post in threaded view
|

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

BartC-3
In reply to this post by Eddilbert Macharia
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

Reply | Threaded
Open this post in threaded view
|

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

Chris Angelico
On Wed, Jun 3, 2015 at 8:20 PM, BartC <bc at 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

Reply | Threaded
Open this post in threaded view
|

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

BartC-3
In reply to this post by BartC-3
On 03/06/2015 11:38, Chris Angelico wrote:

> On Wed, Jun 3, 2015 at 8:20 PM, BartC <bc at 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



Reply | Threaded
Open this post in threaded view
|

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

BartC-3
In reply to this post by BartC-3
On 03/06/2015 11:20, BartC wrote:

> '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.)

(That's not right. What I call 'genfield' is also resolved at runtime at
the point of use. But the possibilities are very small (often just two),
and must be an attribute the compiler knew about. Python-like open-ended
attribute names have a separate mechanism, although I haven't
implemented it yet...)

--
Bartc

Reply | Threaded
Open this post in threaded view
|

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

Marko Rauhamaa
In reply to this post by BartC-3
BartC <bc at 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

Reply | Threaded
Open this post in threaded view
|

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

Marco Buttu-2
In reply to this post by BartC-3
On 03/06/2015 13:08, BartC wrote:

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

If we really want to keep it simple, we can take this starting point:

http://en.wikipedia.org/wiki/Object_(computer_science)

If we agree with the Wikipedia definition:

``In the class-based object-oriented programming paradigm, "object"
refers to a particular instance of a class...``

than we can say in Python everything is an object, because everything is
an instance of a class. And  of course, object is synonimous for instance:

 >>> (1, 2, 3).foo
Traceback (most recent call last):
    ...
AttributeError: 'tuple' object has no attribute 'foo'

--
Marco Buttu

INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711 80 217
Email: mbuttu at oa-cagliari.inaf.it


Reply | Threaded
Open this post in threaded view
|

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

Chris Angelico
In reply to this post by BartC-3
On Wed, Jun 3, 2015 at 9:08 PM, BartC <bc at freeuk.com> wrote:

> On 03/06/2015 11:38, Chris Angelico wrote:
>>
>> On Wed, Jun 3, 2015 at 8:20 PM, BartC <bc at 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.

Right. My point is that it starts out meaningless, because "variable"
doesn't help with anything. "Value" might help, in which case what
you're saying is that every value in Python is an object (in contrast
to Java, where some aren't). But not all objects are referenced by
names, so "variable" isn't very helpful here.

ChrisA

Reply | Threaded
Open this post in threaded view
|

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

Eddilbert Macharia
In reply to this post by Eddilbert Macharia
Hello guys,

After i read http://python-history.blogspot.com/2009/02/first-class-everything.html .

where Guidos says "One of my goals for Python was to make it so that all objects were "first class." By this, I meant that I wanted all objects that could be named in the language (e.g., integers, strings, functions, classes, modules, methods, etc.) to have equal status. That is, they can be assigned to variables, placed in lists, stored in dictionaries, passed as arguments, and so forth."

I think i was right to say:

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

Reply | Threaded
Open this post in threaded view
|

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

Ian Kelly-2
In reply to this post by Marko Rauhamaa
On Wed, Jun 3, 2015 at 2:57 AM, Marko Rauhamaa <marko at pacujo.net> wrote:

> Steven D'Aprano <steve+comp.lang.python at 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!

Reply | Threaded
Open this post in threaded view
|

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

BartC-3
In reply to this post by Marko Rauhamaa
On 03/06/2015 13:08, Marko Rauhamaa wrote:

> BartC <bc at 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


Reply | Threaded
Open this post in threaded view
|

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

Mark Lawrence
On 03/06/2015 17:00, BartC wrote:

> On 03/06/2015 13:08, Marko Rauhamaa wrote:
>> BartC <bc at 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


Reply | Threaded
Open this post in threaded view
|

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

Michael Torrie
In reply to this post by BartC-3
On 06/03/2015 10:00 AM, BartC wrote:
> The others all give True in all cases. It seems that older Python
> versions have a purer object model.

No.  It's just an under-the-hood optimization that the interpreter is
making.  It's an implementation detail that you should never rely on.
It says nothing about the purity of the object model.  Immutable objects
can be optimized ("interred" is the word often used) by reusing the same
object over and over when the interpreter can.


Reply | Threaded
Open this post in threaded view
|

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

Terry Reedy
In reply to this post by BartC-3
On 6/3/2015 6:20 AM, BartC wrote:

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

That is clear enough in itself, but be aware that many people use
'variable' as a synonym for typeless names rather than typed values.

--
Terry Jan Reedy



12345