Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are Python's type "objects" exactly?

Tags:

python

I'm just beginning to learn Python. I'm finding the type system a little hard to understand. I have a number of questions, but primarily and to cut a long story short; The documentation states:

"All data in a Python program is represented by objects ... Every object has an identity, a type and a value."

No problem. But beyond that its not really described what "objects" are. For example the docs don't even cover that these "objects" support a dot operator - from my PoV they could be some in memory data structure not exposed to the user beyond id(), type() etc. However I gather there is some underlying meta object interface similar to that described for the class instance type object in the docs. To work from an example:

If I do this on a class instance "x":

x.__class__.__name__

I get the name of its class. I understand that. The documentation describes the __class__ and __name__ properties of class instances and class type objects. If I do this [].__class__.__name__ I get "list". Similarly int(1).__class__.__name__ gives "int". Its ambiguous to me exactly what is going on under the hood, and I would like clarification. So my questions are:

  • Whats the relationship between a type type "objects" and "class instances" type objects?
  • Can I assume the ~meta API to in-built type objects is the same as that of "class instance" type objects?
  • If so, what is this interface and where is it documented?
  • In general, what are "objects" that correspond to built-in types, and how are they implemented?
like image 340
spinkus Avatar asked Apr 21 '14 12:04

spinkus


3 Answers

I'll answer the 1,2 question first, then 4th then 3rd:

  • "Whats the relationship between a type type "objects" and "class instances" type objects?"
  • "Can I assume the ~meta API to in-built type objects is the same as that of "class instance" type objects?"

They are the same, and yes they share a common API. When the documentation describes built in types as "objects", or class instances as "objects", or a class or whatever as an "object" ... they are talking about exactly the same language construct.

  • "In general, what are "objects" ..."

The object is a foundational language feature in Python that supports attributes and behaviors much like other OOPLs. All Python objects also have a class much like other classed based OOPLs. The object class is the base of the class hierarchy in Python. Thus all classes are subclasses of the object class, and all the aforementioned "objects" and instances of object - by way of inheritance.

It's worth first pointing out explicitly that in Python (2.2 and above) "type" and "class" mean the same thing (for all intents and purposes). So "int", and the rest of the so called builtin types are classes (which are represented as objects of course). For example this x = int(1) calls the int class (object) to construct an int instance object, x.

It's true to say there are two types of object in Python; "type" objects, or those that represent types, and "non-type" objects - those that don't. But it's equally true to say there are two type of integers; zero, and not zero. It doesn't mean much: Everything in Python is an object including classes. Since classes form a kind object, they are all instances of a class called "type". The type object is also an instance of type. Note you can inspect the inheritance hierarchy of class by examining the _bases_ attribute of a class object. In all cases it leads back to the object class - of course. See https://www.eecg.utoronto.ca/~jzhu/csc326/readings/metaclass-class-instance.pdf for further details on this.

  • "...where is it all documented?"

Well, that's actually a good question. It should be covered in the Data Model section of the language reference, but it is sort of skimmed over. The constructor for object objects, object (that made sense) is a built in and documented with the rest of the builtins here. Also the Classes chapter of The Python Tutorial also covers this area a bit.

like image 149
spinkus Avatar answered Nov 09 '22 12:11

spinkus


It's a bit hard to understand what you are asking.

A type is the class of a class. Like everything else in Python, classes themselves are objects, and you can pass them around, assign them to variables, etc. If you ask a class what its class is, you will get the answer type. If you ask a class instance what its class is, you will of course get the class.

>>> type(int)
<type 'type'>
>>> type(1)
<type 'int'>

>>> class Foo(object):
...   pass
>>> type(Foo)
<type 'type'>
>>> obj = Foo()
>>> type(obj)
<class '__main__.Foo'>

(here the function type(x) is another way of doing x.__class__.)

like image 33
Daniel Roseman Avatar answered Nov 09 '22 13:11

Daniel Roseman


Python types are ordinary objects just like anything else (everything is an object). Being a type or an instance is a matter of the object's semantics, a role that it plays.

Class, or type, is an object that holds information about how to construct a certain kind of objects and what that kind of objects can do.

In Python 3, class and type are basically the same thing. The term 'class' is more often used to describe complex types (library or user-defined), while the term 'type' is used to describe basic primitives (e.g. integer, string, list) or any type in general.

(I don't know if some of built-in types are implemented differently than user-defined ones; to start with, there are several Python interpreters out there which may differ from one another. What's important is that conceptually, builtin types and user-defined types are not different).

An instance of a type (class) is an object that was constructed using the information of its type object and which behaves the way its type object advertises.

Instance objects are connected to their type objects via that __class__ property (though it's better to use type() function to get object's type). This connection is an ordinary reference that one object holds to another, its implementation is no special except that interpreter will use this reference to implement subclassing and reflection. Sometimes it can even change in runtime.

like image 29
hamstergene Avatar answered Nov 09 '22 12:11

hamstergene