Re: Over 30 types of variables available in python ?

Discussion in 'Python' started by chaouche yacine, Jan 7, 2013.

  1. Thanks for all your comments. It appears to me that there is a slight confusion between types and classes then, plus other entities (protocols ?)

    So my question is : is there a notion of "type" in python, like in other languages (integers, booleans, floats, strings, characters (in c)) ? if so, can you give a list of the available "types" ?


    The documentation (http://docs.python.org/2/library/stdtypes.html) states "The principal built-in types are numerics, sequences, mappings, files, classes,
    instances and exceptions."






    ________________________________
    From: Terry Reedy <>
    To:
    Sent: Monday, January 7, 2013 1:45 AM
    Subject: Re: Over 30 types of variables available in python ?

    On 1/6/2013 6:12 PM, chaouche yacine wrote:
    >
    > booleans
    > ints, floats, longs, complexes
    > strings, unicode strings
    > lists, tuples, dictionaries, dictionary views, sets, frozensets,
    > buffers, bytearrays, slices
    > functions, methods, code objects,modules,classes, instances, types,
    > nulls (there is exactly one object of type Null which is None),
    > tracebacks, frames
    > generators, iterators, xranges,
    > files,
    > memoryviews,
    > context managers,
    >
    > These are all listed in this page
    > http://docs.python.org/2/library/stdtypes.html as built-in types.


    They would better be called classes. Every thing is Python is an instance of a class. 'Iterator' and 'context manager' are protocols that multiple classes can follow, not classes themselves.

    > Am I
    > getting anything wrong here ? I'm a bit confused about it. I have never
    > seen so many types in the few programming languages I saw.


    C has up to 8 integer types, Python 3 just 1. Most of the above are structures in C, which may or may not by typedef-ed, or classes in C++. If you counted all the structures and classes that come with C or C++, you would find a comparable number.

    C stdlib has a pointer to file structure type, which is equivalent to Python's file class. It is true that C does not come with hashed arrays (sets) and hashed associative arrays (dicts), but they are often needed. So C programmers either reinvent the wheel or include a third-party library. C also has frame structure, but they are normally hidden. C programmers do not have easy direct access. However, virus writers learn to work with them ;-(.

    -- Terry Jan Reedy

    -- http://mail.python.org/mailman/listinfo/python-list
    chaouche yacine, Jan 7, 2013
    #1
    1. Advertising

  2. On Mon, 07 Jan 2013 00:53:26 -0800, chaouche yacine wrote:

    > Thanks for all your comments. It appears to me that there is a slight
    > confusion between types and classes then, plus other entities (protocols
    > ?)



    In Python 3, types and classes are synonyms. They mean the same thing.

    In Python 2, there is a very subtle difference, due to the existence of
    "old style" or "classic" classes, for backward compatibility, which are
    not identical to "new style" classes, also known as types. But they are a
    "kind of type" -- although there are some differences, you can consider
    them to be the same sort of thing.


    > So my question is : is there a notion of "type" in python, like in other
    > languages (integers, booleans, floats, strings, characters (in c)) ? if
    > so, can you give a list of the available "types" ?


    Yes, and no.

    Yes, there is a notation of type in Python which is exactly the same sort
    of notation of type in other languages, such as C. The difference between
    C and Python is not in the notation of "type", but in the notation of
    "variable" or "name".

    In C, *variables* have a type. If you declare a variable x to be a float,
    then three things happen:

    * the C compiler creates a fixed memory location and calls it "x";

    * the C compiler interprets the *value* of that memory location (which is
    actually just a bunch of bytes) as a float;

    * the C compiler will only ever place values into that memory location if
    it thinks that the value is a float, or compatible with a float.

    Because all values are bunches of bytes, you can (with a bit of effort)
    grab the bytes from any location, without caring what the type the
    compiler considers it. Sometimes this is useful; more often it is a
    source of bugs.

    In Python, *names* have no type, but *objects* (values) do. Because names
    are untyped, the one name (say, x) might be store a float one minute,
    then later have a list assigned to it, then a string, then a float again.
    But at any instant, whatever the value of x, it is an object, and objects
    always have a type no matter what name they are bound to. The type
    information is *part of the object*, rather than part of the name.

    Because Python considers all objects to be typed, there is no concept of
    extracting the raw bytes from a list. (Of course lists actually are made
    out of bytes, but you cannot access them from pure Python code.)


    So, yes, Python has types, just as C has types, but the difference is
    that Python associates the type with the *value* (object) rather than a
    storage location (variable).


    But no, we can't give a complete list of all types, because there is no
    limit to the number of types. There are a certain number of built-in
    types, plus many more types which are available from the standard
    library, plus an infinite number of custom types you can create yourself.

    You can get a list of the common built-in types and the standard library
    types from the Fine Manual:

    http://docs.python.org/2/library/

    See also:

    http://docs.python.org/2/reference/datamodel.html


    There are also built-in types which are essentially undocumented, and
    used as implementation details of higher-level objects like functions,
    methods, and so forth. You are not expected to use these directly.
    Instead, you just use the function itself.


    If you are unfamiliar with Object Oriented Programming, you can broadly
    speaking consider types to be like smart structs that carry code around
    with them. There is no limit to the number of possible structs, and
    likewise there is no limit to the number of possible types.


    > The documentation (http://docs.python.org/2/library/stdtypes.html)
    > states "The principal built-in types are numerics, sequences, mappings,
    > files, classes, instances and exceptions."


    Yes, they are the principal types, but there are many others.

    There are three different built-in numeric types:

    int
    long
    float

    plus Decimal and Fraction in the standard library;

    There are two standard built-in sequence types:

    list
    tuple

    plus others in the standard library, such as namedtuple;

    There is one standard built-in mapping type:

    dict

    plus at least two more in the standard library, defaultdict and
    ordereddict;

    etc. You can read the docs more easily than I can copy the types out.



    --
    Steven
    Steven D'Aprano, Jan 7, 2013
    #2
    1. Advertising

  3. chaouche yacine

    marduk Guest

    So I guess if one *really* wanted to compare C variables to Python
    variables, you could say that all python variables are of type void*
    except Python does all mallocs/frees and the casting for you.
    marduk, Jan 7, 2013
    #3
  4. chaouche yacine

    Dave Angel Guest

    On 01/07/2013 09:32 AM, marduk wrote:
    > So I guess if one *really* wanted to compare C variables to Python
    > variables, you could say that all python variables are of type void*
    > except Python does all mallocs/frees and the casting for you.


    A better analogy would be to C++, and all names would be something like
    shared_ptr<object*>. And (except for old-style classes) all actual data
    is of a type derived from object.





    --

    DaveA
    Dave Angel, Jan 7, 2013
    #4
  5. On Tue, Jan 8, 2013 at 1:45 AM, Dave Angel <> wrote:
    > On 01/07/2013 09:32 AM, marduk wrote:
    >> So I guess if one *really* wanted to compare C variables to Python
    >> variables, you could say that all python variables are of type void*
    >> except Python does all mallocs/frees and the casting for you.

    >
    > A better analogy would be to C++, and all names would be something like
    > shared_ptr<object*>. And (except for old-style classes) all actual data
    > is of a type derived from object.


    But yes, a C pointer variable is closest to a Python local, with
    actual content always stored on the heap.

    ChrisA
    Chris Angelico, Jan 7, 2013
    #5
  6. chaouche yacine

    Rick Johnson Guest

    > On 1-7-2013 2:53:26 AM UTC-6, chaouche yacine wrote:
    >
    > Thanks for all your comments. It appears to me that there
    > is a slight confusion between types and classes then, plus
    > other entities (protocols ?)


    The only "confusion" stems from improper terminology. "Class" is the worst possible word to describe: /"the code written by a programmer to define an object"/.

    This epidemic of transforming words improperly is not only a python problem(as you well know). I believe it is high time we stop designing languages by propagating foolish terminology simply because we have no will to break the "status quo".

    And everybody needs to help push this cause along by refusing to use the word "class" and only use the words "object definition". This is something wecan all do WITHOUT modifying the python source. This is how you get the snowball rolling. However, if we do this for long enough, language designers will start to realize that "class" is NOT the proper terminology and MAYBE they will consider terminology a bit more. Well, a boy can dream...

    We MUST separate the idea of: "an object that lives in memory" from the: "code that defines the object" AND we must do so by wielding intuitive terminology.

    "Just because person X decides to jump off a bridge, that action does not impose person Y to blindly follow"
    Rick Johnson, Jan 11, 2013
    #6
  7. chaouche yacine

    Rick Johnson Guest

    > On 1-7-2013 2:53:26 AM UTC-6, chaouche yacine wrote:
    >
    > Thanks for all your comments. It appears to me that there
    > is a slight confusion between types and classes then, plus
    > other entities (protocols ?)


    The only "confusion" stems from improper terminology. "Class" is the worst possible word to describe: /"the code written by a programmer to define an object"/.

    This epidemic of transforming words improperly is not only a python problem(as you well know). I believe it is high time we stop designing languages by propagating foolish terminology simply because we have no will to break the "status quo".

    And everybody needs to help push this cause along by refusing to use the word "class" and only use the words "object definition". This is something wecan all do WITHOUT modifying the python source. This is how you get the snowball rolling. However, if we do this for long enough, language designers will start to realize that "class" is NOT the proper terminology and MAYBE they will consider terminology a bit more. Well, a boy can dream...

    We MUST separate the idea of: "an object that lives in memory" from the: "code that defines the object" AND we must do so by wielding intuitive terminology.

    "Just because person X decides to jump off a bridge, that action does not impose person Y to blindly follow"
    Rick Johnson, Jan 11, 2013
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Knight
    Replies:
    2
    Views:
    739
    Steve Knight
    Oct 10, 2003
  2. j_mckitrick
    Replies:
    2
    Views:
    551
    Cameron Laird
    Nov 13, 2004
  3. chaouche yacine
    Replies:
    0
    Views:
    139
    chaouche yacine
    Jan 6, 2013
  4. Dave Angel
    Replies:
    0
    Views:
    133
    Dave Angel
    Jan 6, 2013
  5. Terry Reedy
    Replies:
    0
    Views:
    133
    Terry Reedy
    Jan 7, 2013
Loading...

Share This Page