Help understanding the decisions *behind* python?

Discussion in 'Python' started by Phillip B Oldham, Jul 20, 2009.

  1. My colleagues and I have been working with python for around 6 months
    now, and while we love a lot of what python has done for us and what
    it enables us to do some of the decisions behind such certain
    data-types and their related methods baffle us slightly (when compared
    to the decisions made in other, similarly powerful languages).

    Specifically the "differences" between lists and tuples have us
    confused and have caused many "discussions" in the office. We
    understand that lists are mutable and tuples are not, but we're a
    little lost as to why the two were kept separate from the start. They
    both perform a very similar job as far as we can tell.

    Consider the following:

    >>> x = [2,1,3]
    >>> x.sort()
    >>> print x

    [1, 2, 3]

    Now, if the sort operations were unable to affect the original
    structure of the list (as in JavaScript) you'd effectively have a
    tuple which you could add/remove from, and the example above would
    look more like:

    >>> x = [2,1,3]
    >>> print x.sort()

    [1, 2, 3]
    >>> print x

    [2,1,3]

    This make a lot more sense to us, and follows the convention from
    other languages. It would also mean chaining methods to manipulate
    lists would be easier:

    >>> x = [2,1,3]
    >>> print x.sort()[0]

    3
    >>> print x

    [2,1,3]

    We often find we need to do manipulations like the above without
    changing the order of the original list, and languages like JS allow
    this. We can't work out how to do this in python though, other than
    duplicating the list, sorting, reversing, then discarding.

    We're not looking to start any arguments or religious wars and we're
    not asking that python be changed into something its not. We'd simply
    like to understand the decision behind the lists and tuple structures.
    We feel that in not "getting" the difference between the two types we
    may be missing out on using these data structures to their full
    potential.
     
    Phillip B Oldham, Jul 20, 2009
    #1
    1. Advertising

  2. On Jul 20, 12:27 pm, Phillip B Oldham <>
    wrote:
    > ...
    > Specifically the "differences" between lists and tuples have us
    > confused and have caused many "discussions" in the office. We
    > understand that lists are mutable and tuples are not, but we're a
    > little lost as to why the two were kept separate from the start. They
    > both perform a very similar job as far as we can tell.
    > ...


    There's no hard-set rules, but tuples are typically used to hold
    collections of heterogeneous data, e.g. (10, "spam", 3.21). As has
    been mentioned, such a tuple can be used as a dictionary key, whereas
    a list cannot be used as a dictionary key, because it is mutable.

    Lists, on the other hand, typically hold collections of homogeneous
    data, e.g. [1, 2, 5] or ["spam", "eggs", "sausage"].

    Of course, you'll also see plenty of examples of tuples containing
    homogeneous data and lists containing heterogeneous data :)
     
    Anthony Tolle, Jul 20, 2009
    #2
    1. Advertising

  3. On Jul 20, 6:08 pm, Duncan Booth <> wrote:
    > The main reason why you need both lists and tuples is that because a tuple
    > of immutable objects is itself immutable you can use it as a dictionary
    > key.


    Really? That sounds interesting, although I can't think of any real-
    world cases where you'd use something like that.
     
    Phillip B Oldham, Jul 20, 2009
    #3
  4. On Mon, 2009-07-20 at 12:26 -0700, Phillip B Oldham wrote:
    > On Jul 20, 6:08 pm, Duncan Booth <> wrote:
    > > The main reason why you need both lists and tuples is that because a tuple
    > > of immutable objects is itself immutable you can use it as a dictionary
    > > key.

    >
    > Really? That sounds interesting, although I can't think of any real-
    > world cases where you'd use something like that.


    Well, if you wanted to index a dictionary by coordinates, you might do
    something like this:


    fleet = {}
    fleet[9,4] = 'destroyer'
    fleet[8,4] = 'destroyer'
    fleet[3,5] = 'aircraftcarrier'
    fleet[4,5] = 'aircraftcarrier'
    fleet[5,5] = 'aircraftcarrier'
    fleet[6,5] = 'aircraftcarrier'
    fleet[8,0] = 'battleship'
    fleet[8,1] = 'battleship'
    fleet[8,2] = 'battleship'


    def checkattack(x, y, fleet):
    if x,y in fleet:
    return "You hit my %s' % fleet[x,y]

    Maybe not the best implementation of Battleship, but you get the idea.
     
    J. Cliff Dyer, Jul 20, 2009
    #4
  5. >>>>> Duncan Booth <> (DB) wrote:

    >DB> Phillip B Oldham <> wrote:
    >>> This make a lot more sense to us, and follows the convention from
    >>> other languages. It would also mean chaining methods to manipulate
    >>> lists would be easier:
    >>>
    >>>>>> x = [2,1,3]
    >>>>>> print x.sort()[0]
    >>> 3
    >>>>>> print x
    >>> [2,1,3]


    >DB> You already have a way to do what you want:


    >>>>> x = [2,1,3]
    >>>>> print sorted(x)[0]

    >DB> 3


    What kind of Python produces that?
    --
    Piet van Oostrum <>
    URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
    Private email:
     
    Piet van Oostrum, Jul 20, 2009
    #5
  6. Phillip B Oldham

    Chris Rebert Guest

    On Mon, Jul 20, 2009 at 2:23 PM, Piet van Oostrum<> wrote:
    >>>>>> Duncan Booth <> (DB) wrote:

    >
    >>DB> Phillip B Oldham <> wrote:
    >>>> This make a lot more sense to us, and follows the convention from
    >>>> other languages. It would also mean chaining methods to manipulate
    >>>> lists would be easier:
    >>>>
    >>>>>>> x = [2,1,3]
    >>>>>>> print x.sort()[0]
    >>>> 3
    >>>>>>> print x
    >>>> [2,1,3]

    >
    >>DB> You already have a way to do what you want:

    >
    >>>>>> x = [2,1,3]
    >>>>>> print sorted(x)[0]

    >>DB> 3

    >
    > What kind of Python produces that?


    Assuming you're referring to the latter example, it was added in version 2.4
    If you meant the former example, I think that's purely pseudo-Python.

    Cheers,
    Chris
    --
    http://blog.rebertia.com
     
    Chris Rebert, Jul 20, 2009
    #6
  7. Phillip B Oldham

    Paul Moore Guest

    2009/7/20 Chris Rebert <>:
    > On Mon, Jul 20, 2009 at 2:23 PM, Piet van Oostrum<> wrote:
    >>>>>>> x = [2,1,3]
    >>>>>>> print sorted(x)[0]
    >>>DB> 3

    >>
    >> What kind of Python produces that?

    >
    > Assuming you're referring to the latter example, it was added in version 2.4
    > If you meant the former example, I think that's purely pseudo-Python.


    I think he was referring to the fact that the result should be 1, not 3.

    Paul.
     
    Paul Moore, Jul 20, 2009
    #7
  8. Phillip B Oldham <> writes:

    > On Jul 20, 6:08 pm, Duncan Booth <> wrote:
    >> The main reason why you need both lists and tuples is that because a tuple
    >> of immutable objects is itself immutable you can use it as a dictionary
    >> key.

    >
    > Really? That sounds interesting, although I can't think of any real-
    > world cases where you'd use something like that.


    An application visiting files on a filesystem recursively needs a
    dictionary or set keyed by (st_dev, st_ino) to make sure it doesn't
    visit the same file twice. Memoization implementation (of a cache for
    results of function application) might need to use a dictionary to map
    function arguments, a tuple, to the function result.
     
    Hrvoje Niksic, Jul 20, 2009
    #8
  9. Chris Rebert <> writes:

    >>>>>>> x = [2,1,3]
    >>>>>>> print sorted(x)[0]
    >>>DB> 3

    >>
    >> What kind of Python produces that?

    >
    > Assuming you're referring to the latter example, it was added in version 2.4
    > If you meant the former example, I think that's purely pseudo-Python.


    sorted([2, 1, 3])[0] evaluates to 1, not 3.
     
    Hrvoje Niksic, Jul 20, 2009
    #9
  10. Phillip B Oldham <> writes:

    > We often find we need to do manipulations like the above without
    > changing the order of the original list, and languages like JS allow
    > this. We can't work out how to do this in python though, other than
    > duplicating the list, sorting, reversing, then discarding.


    If you just want a one-liner, and you don't care about speed you can
    do the following (but I don't think this is considered best practice)

    >>> x = [2,1,3]
    >>> print list(sorted(x))

    [1, 2, 3]
    >>> print x

    [2, 1, 3]

    Niels
     
    Niels L. Ellegaard, Jul 20, 2009
    #10
  11. >>>>> Paul Moore <> (PM) wrote:

    >PM> 2009/7/20 Chris Rebert <>:
    >>> On Mon, Jul 20, 2009 at 2:23 PM, Piet van Oostrum<> wrote:
    >>>>>>>>> x = [2,1,3]
    >>>>>>>>> print sorted(x)[0]

    >DB> 3
    >>>>
    >>>> What kind of Python produces that?
    >>>
    >>> Assuming you're referring to the latter example, it was added in version 2.4
    >>> If you meant the former example, I think that's purely pseudo-Python.


    >PM> I think he was referring to the fact that the result should be 1, not 3.


    The underlying thought was that you should copy and paste examples from
    a real Python interpreter.
    --
    Piet van Oostrum <>
    URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
    Private email:
     
    Piet van Oostrum, Jul 21, 2009
    #11
  12. On Monday 20 July 2009 21:26:07 Phillip B Oldham wrote:
    > On Jul 20, 6:08 pm, Duncan Booth <> wrote:
    > > The main reason why you need both lists and tuples is that because a
    > > tuple of immutable objects is itself immutable you can use it as a
    > > dictionary key.

    >
    > Really? That sounds interesting, although I can't think of any real-
    > world cases where you'd use something like that.


    simplest is something like a point in the cartesian plane with
    an associated attribute like colour.

    - Hendrik
     
    Hendrik van Rooyen, Jul 21, 2009
    #12
  13. Phillip B Oldham

    Inky 788 Guest

    On Jul 20, 12:27 pm, Phillip B Oldham <>
    wrote:
    > [snip] We
    > understand that lists are mutable and tuples are not, but we're a
    > little lost as to why the two were kept separate from the start. They
    > both perform a very similar job as far as we can tell.


    My guess is that it was probably for optimization reasons long ago.
    I've never heard a *good* reason why Python needs both.
     
    Inky 788, Jul 21, 2009
    #13
  14. >>>>> Hendrik van Rooyen <> (HvR) wrote:

    >HvR> On Monday 20 July 2009 21:26:07 Phillip B Oldham wrote:
    >>> On Jul 20, 6:08 pm, Duncan Booth <> wrote:
    >>> > The main reason why you need both lists and tuples is that because a
    >>> > tuple of immutable objects is itself immutable you can use it as a
    >>> > dictionary key.
    >>>
    >>> Really? That sounds interesting, although I can't think of any real-
    >>> world cases where you'd use something like that.


    >HvR> simplest is something like a point in the cartesian plane with
    >HvR> an associated attribute like colour.


    There are numerous other examples. Anytime you need a key that is not a
    single object but composed of more than one:
    Name + birthday
    Street + number + City
    Student + Course
    etc.
    --
    Piet van Oostrum <>
    URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
    Private email:
     
    Piet van Oostrum, Jul 21, 2009
    #14
  15. Phillip B Oldham

    David Smith Guest

    Piet van Oostrum wrote:
    >>>>>> Hendrik van Rooyen <> (HvR) wrote:

    >
    >> HvR> On Monday 20 July 2009 21:26:07 Phillip B Oldham wrote:
    >>>> On Jul 20, 6:08 pm, Duncan Booth <> wrote:
    >>>>> The main reason why you need both lists and tuples is that because a
    >>>>> tuple of immutable objects is itself immutable you can use it as a
    >>>>> dictionary key.
    >>>> Really? That sounds interesting, although I can't think of any real-
    >>>> world cases where you'd use something like that.

    >
    >> HvR> simplest is something like a point in the cartesian plane with
    >> HvR> an associated attribute like colour.

    >
    > There are numerous other examples. Anytime you need a key that is not a
    > single object but composed of more than one:
    > Name + birthday
    > Street + number + City
    > Student + Course
    > etc.


    Compound keys (like what's listed above) can also be used for sorting
    lists of dictionaries using DSU style sorting. Something I believe (and
    I could be wrong) won't work with mutable types like lists.

    --David
     
    David Smith, Jul 21, 2009
    #15
  16. >>>>> David Smith <> (DS) wrote:

    >DS> Piet van Oostrum wrote:
    >>>>>>>> Hendrik van Rooyen <> (HvR) wrote:
    >>>

    >HvR> On Monday 20 July 2009 21:26:07 Phillip B Oldham wrote:
    >>>>>> On Jul 20, 6:08 pm, Duncan Booth <> wrote:
    >>>>> The main reason why you need both lists and tuples is that because a
    >>>>> tuple of immutable objects is itself immutable you can use it as a
    >>>>> dictionary key.
    >>>>>> Really? That sounds interesting, although I can't think of any real-
    >>>>>> world cases where you'd use something like that.
    >>>

    >HvR> simplest is something like a point in the cartesian plane with
    >HvR> an associated attribute like colour.
    >>>
    >>> There are numerous other examples. Anytime you need a key that is not a
    >>> single object but composed of more than one:
    >>> Name + birthday
    >>> Street + number + City
    >>> Student + Course
    >>> etc.


    >DS> Compound keys (like what's listed above) can also be used for sorting
    >DS> lists of dictionaries using DSU style sorting. Something I believe (and
    >DS> I could be wrong) won't work with mutable types like lists.


    For sorting there is no problem with mutable arrays as long as you don't
    mutate them during the sorting process (for example in the comparison
    routine). Doing that would be extremely perverse. And there is no
    enforcement of that.
    --
    Piet van Oostrum <>
    URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
    Private email:
     
    Piet van Oostrum, Jul 21, 2009
    #16
  17. Phillip B Oldham

    Simon Forman Guest

    On Jul 20, 12:27 pm, Phillip B Oldham <>
    wrote:
    > My colleagues and I have been working with python for around 6 months
    > now, and while we love a lot of what python has done for us and what
    > it enables us to do some of the decisions behind such certain
    > data-types and their related methods baffle us slightly (when compared
    > to the decisions made in other, similarly powerful languages).
    >
    > Specifically the "differences" between lists and tuples have us
    > confused and have caused many "discussions" in the office. We
    > understand that lists are mutable and tuples are not, but we're a
    > little lost as to why the two were kept separate from the start. They
    > both perform a very similar job as far as we can tell.
    >
    > Consider the following:
    >
    > >>> x = [2,1,3]
    > >>> x.sort()
    > >>> print x

    >
    > [1, 2, 3]
    >
    > Now, if the sort operations were unable to affect the original
    > structure of the list (as in JavaScript) you'd effectively have a
    > tuple which you could add/remove from, and the example above would
    > look more like:
    >
    > >>> x = [2,1,3]
    > >>> print x.sort()

    > [1, 2, 3]
    > >>> print x

    >
    > [2,1,3]
    >
    > This make a lot more sense to us, and follows the convention from
    > other languages. It would also mean chaining methods to manipulate
    > lists would be easier:
    >
    > >>> x = [2,1,3]
    > >>> print x.sort()[0]

    > 3


    (As others have already pointed out this would print 1, not 3.)

    > >>> print x

    >
    > [2,1,3]
    >
    > We often find we need to do manipulations like the above without
    > changing the order of the original list, and languages like JS allow
    > this. We can't work out how to do this in python though, other than
    > duplicating the list, sorting, reversing, then discarding.


    In this case you can use:

    >>> x = [2,1,3]
    >>> print min(x)

    1

    (There's also a max() function.)

    > We're not looking to start any arguments or religious wars and we're
    > not asking that python be changed into something its not. We'd simply
    > like to understand the decision behind the lists and tuple structures.
    > We feel that in not "getting" the difference between the two types we
    > may be missing out on using these data structures to their full
    > potential.



    One way to think about tuples (as distinct from lists) is as a short-
    hand version of Pascal's 'record' type, or C's 'struct' (with the
    caveats that the fields are not named, only indexed, and the types of
    the fields are implied by use, not explicitly declared.)

    (FWIW: http://en.wikipedia.org/wiki/Record_(computer_science) )

    Broadly speaking, lists are useful for things like stacks and queues,
    and sorting, while tuples are useful for aggregating heterogeneous
    data into coherent units, and you can hash them (provided their
    contents are also hashable.)

    HTH,
    ~Simon
     
    Simon Forman, Jul 21, 2009
    #17
  18. On Tuesday 21 July 2009 15:49:59 Inky 788 wrote:
    > On Jul 20, 12:27 pm, Phillip B Oldham <>
    >
    > wrote:
    > > [snip] We
    > > understand that lists are mutable and tuples are not, but we're a
    > > little lost as to why the two were kept separate from the start. They
    > > both perform a very similar job as far as we can tell.

    >
    > My guess is that it was probably for optimization reasons long ago.
    > I've never heard a *good* reason why Python needs both.


    The good reason is the immutability, which lets you use
    a tuple as a dict key.

    - Hendrik
     
    Hendrik van Rooyen, Jul 22, 2009
    #18
  19. On Tue, 21 Jul 2009 00:39:24 +0200, Niels L. Ellegaard wrote:

    > Phillip B Oldham <> writes:
    >
    >> We often find we need to do manipulations like the above without
    >> changing the order of the original list, and languages like JS allow
    >> this. We can't work out how to do this in python though, other than
    >> duplicating the list, sorting, reversing, then discarding.


    I think Phillip is confused if he thinks that other languages can sort a
    list without modifying or duplicating the original. If you don't
    duplicate the list, how can you sort it without modifying the original?
    The only difference is whether the language makes the duplicate for you,
    or expects you to do it yourself.


    > If you just want a one-liner, and you don't care about speed you can do
    > the following (but I don't think this is considered best practice)
    >
    >>>> x = [2,1,3]
    >>>> print list(sorted(x))


    The call to list is redundant, as sorted() already creates a list.


    But that's the wrong solution to the problem. The OP wants the largest
    (or smallest) item, which he expects to get by sorting, then grabbing the
    first element:

    sorted(alist)[0]

    That requires sorting the entire list, only to throw away everything
    except the first item. A better solution is to use min() and max(),
    neither of which sort the list, so they are much faster.



    --
    Steven
     
    Steven D'Aprano, Jul 22, 2009
    #19
  20. On Tue, 21 Jul 2009 06:49:59 -0700, Inky 788 wrote:

    > On Jul 20, 12:27 pm, Phillip B Oldham <> wrote:
    >> [snip] We
    >> understand that lists are mutable and tuples are not, but we're a
    >> little lost as to why the two were kept separate from the start. They
    >> both perform a very similar job as far as we can tell.

    >
    > My guess is that it was probably for optimization reasons long ago. I've
    > never heard a *good* reason why Python needs both.


    Suppose you could do this:

    key = [1, 2]
    adict = {key: 'x', [1, 1]: 'y'}

    This would work as expected:

    adict[ [1, 2] ]
    => returns 'x'

    adict[ [1, 1] ]
    => returns 'y'

    But what happens if you mutate the key?

    key[1] = 0
    adict[ [1, 2] ]
    => raises KeyError

    Okay, that's bad. What's even worse is this:

    key[1] = 1
    adict[ [1, 1] ]
    => should it return 'x' or 'y'?


    The solution is to disallow mutable objects like lists from being used as
    keys in dicts, and to allow immutable list-like tuples instead.



    --
    Steven
     
    Steven D'Aprano, Jul 22, 2009
    #20
    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. JTS
    Replies:
    0
    Views:
    351
  2. Replies:
    0
    Views:
    901
  3. Replies:
    15
    Views:
    657
    David Graham
    Feb 28, 2006
  4. Jocke P
    Replies:
    11
    Views:
    741
    Samuel Barber
    Aug 27, 2003
  5. Alf P. Steinbach
    Replies:
    7
    Views:
    3,092
    chris
    Jan 24, 2005
Loading...

Share This Page