Why are tuples immutable?

Discussion in 'Python' started by Steve Holden, Dec 13, 2004.

  1. Steve Holden

    Steve Holden Guest

    jfj wrote:

    >
    > Yo.
    >
    > Why can't we __setitem__ for tuples?
    > The way I see it is that if we enable __setitem__ for tuples there
    > doesn't seem to be any performance penalty if the users don't use it
    > (aka, python performance independent of tuple mutability).
    >
    > On the other hand, right now we have to use a list if we want to
    > __setitem__ on a sequence. If we could use tuples in the cases where
    > we want to modify items but not modify the length of the sequence,
    > programs could be considerably faster. Yes?
    >
    > Enlighten me.
    >
    > G.
    >

    Well, the best answer may be "tuples are immutable because otherwise
    there wouldn't be an immutable sequence type".

    There have been many discussions on this topic (not that I'm blaming you
    for being unaware of them), and normally when someone raises this topic
    there's a flurry of nbew justifications for the existing behavior. The
    bottom line seems to be that Guido wanted something that corresponds to
    a mathematical tuple, which is an ordered collection of items of
    (potentially) different types.

    Of course there's nothing much to stop you using lists instead of
    tuples, except the rare piece of code that insists on one or the other.

    regards
    Steve
    --
    http://www.holdenweb.com
    http://pydish.holdenweb.com
    Holden Web LLC +1 800 494 3119
     
    Steve Holden, Dec 13, 2004
    #1
    1. Advertising

  2. Steve Holden

    jfj Guest

    Yo.

    Why can't we __setitem__ for tuples?
    The way I see it is that if we enable __setitem__ for tuples there
    doesn't seem to be any performance penalty if the users don't use it
    (aka, python performance independent of tuple mutability).

    On the other hand, right now we have to use a list if we want to
    __setitem__ on a sequence. If we could use tuples in the cases where
    we want to modify items but not modify the length of the sequence,
    programs could be considerably faster. Yes?

    Enlighten me.

    G.
     
    jfj, Dec 13, 2004
    #2
    1. Advertising

  3. Steve Holden

    Fuzzyman Guest

    Wasn't part of the point, that function call returns ought to be
    immuntable. Otherwise you can accidentally end up modifying objects
    that are referenced in other places ?

    Obviously tuples aren't the *whole* answer... but they help.

    Regards,

    Fuzzy
    http://www.voidspace.org.uk/atlantibots/pythonutils.html
     
    Fuzzyman, Dec 15, 2004
    #3
  4. jfj wrote:
    >
    > Why can't we __setitem__ for tuples?


    It seems from your suggestions here that what you really want is a
    single sequence type, list, instead of two sequence types: tuple and
    list. Under your design, list would support hash, and it would be up to
    the programmer to make sure not to modify a list when using it as a key
    to a dict. The important thing to understand is that, while this is not
    an unreasonable design decision, it's not the design decision that's
    been made for Python.

    Reading the docs and some of GvR's comments on python-dev, my
    understanding is that, while a single sequence type would have sufficed,
    the belief was that there were two mostly non-overlapping sets of tasks
    that one might want to do with sequences. One set of tasks dealt with
    "small collections of related data which may be of different types which
    are operated on as a group"[1] (tuples), while the other set of tasks
    dealt with "hold[ing] a varying number of objects all of which have the
    same type and which are operated on one-by-one"[1] (lists).

    Now, when you use a sequence as a key to a dict, you're operating on the
    sequence as a group, not one-by-one. Given the above conceptions of
    tuple and list then, it is natural to provide tuple with hash support,
    while leaving it out of list.

    Note also that tuples being immutable also falls out of the tuple
    description above too. If you're operating on the sequence as a group,
    then there's no need for __setitem__; __setitem__ is used to operate on
    a sequence one-by-one.

    I understand that you'd like a type that is operated on one-by-one, but
    can also be considered as a group (e.g. is hashable). Personally, I
    don't have any use for such a type, but perhaps others do. The right
    solution in this case is not to try to redefine tuple or list, but to
    write a PEP[2] and suggest a new datatype that serves your purposes.
    I'll help you out and provide you with an implementation: =)

    class hashablelist(list):
    def __hash__(self):
    return hash(tuple(self))

    Now all you need to do is write the Abstract, Motivation and Rationale,
    and persuade the people on c.l.py and python-dev that this is actually a
    useful addition to the language.

    Steve

    [1]
    http://www.python.org/doc/faq/general.html#why-are-there-separate-tuple-and-list-data-types
    [2] http://www.python.org/peps/pep-0001.html
     
    Steven Bethard, Dec 17, 2004
    #4
    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. Fredrik Lundh

    Re: Why are tuples immutable?

    Fredrik Lundh, Dec 13, 2004, in forum: Python
    Replies:
    68
    Views:
    1,193
    Antoon Pardon
    Dec 31, 2004
  2. Jp Calderone

    Re: Why are tuples immutable?

    Jp Calderone, Dec 15, 2004, in forum: Python
    Replies:
    1
    Views:
    309
    Roy Smith
    Dec 15, 2004
  3. Adam DePrince

    Re: Why are tuples immutable?

    Adam DePrince, Dec 16, 2004, in forum: Python
    Replies:
    37
    Views:
    1,228
    Bengt Richter
    Dec 30, 2004
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,270
    Smokey Grindel
    Dec 2, 2006
  5. Jon Reyes
    Replies:
    18
    Views:
    276
    Mitya Sirenef
    Feb 19, 2013
Loading...

Share This Page