43

I just recently started to teach myself how to code. I am currently reading Think Python 2 for python 3 and when it teaches about the type() function, it gives the example type(2) which outputs <class 'int'>. It then states that "the word 'class' is used in the sense of a category; a type is a category of values."

The part that confuses me is that the type() function outputs class instead of type. Also, I'm not sure about the difference between type and class; are string, float point, and integer classes of the type "value", or are they the same thing?

Improve this question
6
  • 6
    Python 3 completed the unification of types and classes (which started way back with Python 2.2). Your book attempts to explain a difference that isn't really there anymore. Commented Mar 12, 2016 at 14:38
  • 1
    Basically a type is class that inherits from object. In Python3, all classes inherit from object, so they are the same thing. Commented Mar 12, 2016 at 14:40
  • 1
    @zondo: that's not quite accurate either. It is related, but that's not a classification I'd use. Commented Mar 12, 2016 at 14:45
  • Maybe find another book... Commented Mar 12, 2016 at 14:47
  • @RickTeachey, what book would you suggest then? Commented Mar 12, 2016 at 14:51

3 Answers 3

Reset to default
48

Once upon a time, Python had both types and classes. Types were built-in objects defined in C; classes were what you built when using a class statement. The two were named differently because you couldn't mix these; classes could not extend types.

This difference was artificial, a limitation in the language implementation. Starting with Python 2.2, the developers of Python have slowly moved towards unifying the two concepts, with the difference all but gone in Python 3. Built-in types are now also labelled classes, and you can extend them at will.

Your book is trying to explain a difference that isn't present in Python anymore. Even in Python 2 the difference is only there in name, since type(2) shows the word 'type' is still used there:

>>> type(2)
<type 'int'>

but you can subclass int just like any other class.

(Python 2 does still have old-style classes, those that don't inherit from object; these are a remnant of the old system from before the unification.)

Improve this answer
Sign up to request clarification or add additional context in comments.

13 Comments

Can you elaborate on what you mean by "defined in C?" So in Python 2, the type would be integer and the class would be 2?
@Jeff: For CPython (the default Python implementation you download from python.org), the implementation for the int type is done in C code, as opposed to user-created classes in Python code.
@Jeff: basically, the terms type and class are interchangeable, but in older Python versions there was a difference still in that you could not mix the two.
@Jeff: Correct on type vs class. I am referring to C programming language. C# and C++ both have been named after C (and both borrow heavily from that language as a basis for their own design).
@MartijnPieters I really appreciate this explanation, because PEP 483 had me confused, as it is asserting "the distinction between classes and types" python.org/dev/peps/pep-0483/#types-vs-classes
|
6

The python hierarchy is Type (Metaclass) -> Class -> Instance. Think of the function type() as going one level up.

If you use the function type() on an instance of an int (any integer) like so: type(123) you will receive the class of the instance which in this case is int. If you will use type() on the class int, you will recieve type type which is the metaclass of int.

Keep in mind metaclasses are advanced technical details of python and you do not need to learn about them at first.

Improve this answer

5 Comments

The text in question is not referencing metaclasses. type is a metaclass, yes, but type(someobject) doesn't return the metaclass, it returns the class for that object. Bringing metaclasses into this only serves to confuse the matter further, I fear.
True that it's not referencing metaclasses but keep in mind type(obj) does return the metaclass of the object in case the object is itself a class. It's causes a bit of confusion, I agree, and that's why I wrote that it's more advanced but the solution is more complete like that I believe.
Yup, and then there is the fun with type(type), etc. But that's all too much information that isn't really relevant to the question what is the difference between a class and a type?
Alright, thanks for the input, will be more careful next time :-)
"Type (Metaclass)" - The term "type" is not synonymous with "metaclass", it's equivalent to "class" (and what "equivalent" means is explained in Martijn's answer).
2

If you are just starting to learn about programming, keep in mind that the terms "type" and "class" are heavily overloaded (used for sometimes different, sometimes synonymous things in different contexts). Rougly speaking, you have...

  • The abstract notion of type. This is something that does not exist when the program runs, but a type checker (or you) can use to identify invalid uses of objects.
  • In many languages, including Python, there is a runtime representation of the types. Using these representations to alter runtime behavior is called "reflection".
  • Then there are classes. So typically (in math), a type refers only to the structure of the data (i.e. fields and their types). In object oriented programming, it is typically necessary to keep the definitions of certain function local to the definition of the class to enforce "data hiding". Anyways, the end result is that we can conceptualize a class as a sort of "type McMenu". You get a type (data structure), interface (public methods), and constructor (usually given by some special syntax or convention - e.g. __init__).
  • Finally, bear in mind that there are static and dynamic types of expressions. The distinction that is relevant to programmers here is the notion of "virtual functions". These don't feel that impressive in Python, but in strong-er-ly typed languages like C++ and C# this is rather powerful and helpful.
Improve this answer

4 Comments

"strong-er-ly typed languages like C++ and C#" - Do you mean "statically typed"? I don't have much breadth of experience on this, but I do know Python is about as strongly typed as they come (e.g. "" + 0 is a type error, unlike JS), but also dynamic (so, that type error happens at runtime, not compile time).
If you want to say that "everything is an object just sometimes you get a runtime error" is strongly typed then I guess we're just playing a word game, why wouldn't python+mypy be as statically typed as they come? AFAIK typically people like to use "strong typing" to refer to the fact that a compilable program should have no runtime type related errors. In C++ you can get around the compiler using (void*) casting or whatever. C# is much closer to this idealism, but there are probably a few trapdoors you can get around the compiler with.
'AFAIK typically people like to use "strong typing" to refer to the fact that a compilable program should have no runtime type related errors.' - Well, the Python compiler doesn't type-check, so that's not applicable. In the world of dynamic languages, in my experience, "strongly typed" means that operations involving incompatible types raise a type error, while "weakly typed" means they'll still return a value, as in JS. And I'm saying "operation" instead of "expression" since the type of an expression isn't known until runtime.
@wjandrea well I'll defer to wikipedia: TLDR they don't have a precise definition, and people like us probably have this same, not useful argument all the time. That's also why I used the very non-technical term stronger-ly typed (as you mentioned the python compiler doesn't type check at all). If you want to change anymore wording of my post go ahead I won't challenge anything.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.