The only differences are that tuples are immutable and that lists have extra methods.

Is there ever a strong need for list-type data to be immutable? Evough to justify a whole extra data-type in the language?

Should they release a python 4 with it removed?

The only thing I can think of is as a default function parameter. This function is okay:

def dothings(a=(1,2)):
    print(a)
    a = (a[0], 3)

But this function misbehaves the second time it is called:

def dothings(a=[1,2]):
    print(a)
    a[1] = 3

But IMO the “mutable arguments” thing is another bug to be fixed in a hypothetical python 4. And even in python 3 you just write the function the recommended way, so there is not such a big problem.

def dothings(a=None):
    if a is None:
        a = [1, 2]
    print(a)
    a[1] = 3

The Python devs are clever guys though. There must be some really important reason to maintain both types?

  • roastpotatothief@lemmy.mlOP
    1·
    3 years ago

    Lists are hererogeneous. This is valid:

    mylist = [1, 1.0, "one"]

    For homogeneous lists, shouldn’t you be using numpy anyway?

    Hashing. This is a interesting point, and it’s not mentioned when people usually compare lists and tuples. I read this. It seems like dicts are both mutable and hashable, and that’s not a problem. Python could implement a __hash__() method for lists too.

    I’m starting to think that it’s purely a whimsical thing. Lists are probably implemented as linked lists in memory, but tuples are probably sequential in memory. So it might be interesting for the devs to have both for these fundamental memory structures available.

    • tmpod@lemmy.pt
      0·
      3 years ago

      While lists can be heterogeneous, but you shouldn’t do it. And no, I don’t want to pull a massive dependency when I don’t need to.

      Regarding dicts, they are also not hashable, I’m unsure where you got that info from. In fact, the SO post you linked states exactly that:

      A hash should remain unchanged throughout the lifetime of the object.

      This means any dynamic structures shouldn’t really have hashes. Both lists and dicts are dynamic, so they are not hashable. A nice and easy way to see this is by trying he following in a Python shell:

      >>> {{}: 1}
TypeError: unhashable type: 'dict'
>>> # or
>>> {[]: 1}
TypeError: unhashable type: 'list'

      And yeah, what you said about the underlying implementation is also true. It is handy and interesting to have both types of structures.

      Edit: hit save instead of preview for some reason lol

      Edit 2: Also forgot to mention that the tuple / list thing is found in functional languages a lot, and also in Rust and whatnot. Remember, lists provide order, while tuples provide structure.

      • roastpotatothief@lemmy.mlOP
        0·
        3 years ago

        from here. this says that dicts are hashable, no?

        A hash is useful in identification of objects. For example, it speeds up data retrieval from a dict, identifying the arbitrary value of a key by a single numerical value from a finite interval - the key’s hash.

        oh wait the keys are hashable but the dict is not. understood. the keys are (immutable) strings.

        all this stylistic stuff, i just really see it as important. maybe because I’m new to programming, i think it’s most important for things to be simple. to remove redundancy and extra complexity. the niche stuff like namedtuple and hashable lists (ie tuples) can be hidden in some package.

        like in numpy there might be 5 methods that all do the same thing. they are there because stylistically, you might prefer one over the other, for neatness or readability etc. i would like to have only one way (or method or data type) to do one thing.