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?

  • tmpod@lemmy.pt
    0·
    3 years ago

    oh wait the keys are hashable but the dict is not.

    Exactly :)

    the keys are (immutable) strings.

    this is partially correct. Keys can be strings (which are immutable, and thus hashable), but they can be anything that implements the magic/dunder method __hash__.

    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.

    named tuples are in a package, while tuples are not. As I said previously, tuples are not immutable/hashable lists, even though you can treat them as such, similar to how you can use integers instead of booleans (in fact, True and False are just aliases to 1 and 0, respectively), despite that being a bad idea. Sure, it adds one extra syntax, but Python aims at being readable, and while you argue this goes against that principle, I argue exactly the opposite. Having different syntax for order (lists), structure (tuples), membership + other math operations (sets) and relation (dicts) is one of the core reasons why Python scripts can and are easy to read. The intentions behind each variable are really clear precisely because you have these fundamental types.

    Now, you’re right in that it may be a bit overwhelming when you’re just starting to know the language, but I’d argue that, if you read good resources, it shouldn’t be very hard to grasp the differences between those types, why they exist and what their use-cases are.

    Also, don’t forget that knowledge is highly cumulative; you have to slowly build your skills, topic by topic, and each step depends on the last one. I hope to have contributed to your better understanding of these Python data structures (which are actually implementations of their broader abstract definitions) :3

    • roastpotatothiefOP
      1·
      3 years ago

      I do see what you mean. I’m not sure why it’s important to have different datatypes for structure/order and not for other things. You could have different syntaxes for volumes, distances, and coefficients. You don’t need a separate data-type for each type of quantity, but you could. It would make certain types of algorithms more readable.

      print(id(True))

      9476448

      print(id(1))

      9788608

      In what sense is True an alias for 1? It’s a boolean not an integer. It really is a different data-type. It would be more reasonable to remove integers and just use floats. Those two are much more similar.

      To go back to another point. I said that for homogeneous ordered lists you should be using numpy instead. But I was thinking, they probably wouldn’t want to promote numpy arrays to a built-in data type just because class’s methods are still developing/evolving quite a fast. The built-in data-types should really be stable across python versions. I know there are other reasons too, how lists are more flexible in some ways.

      It’s an interesting way of thinking, and has this whole “pythonic” philosophy, experimenting with different ways of thinking. Thanks for sharing. As I said these are not the usual explanations I’ve found on the internet. Your explanations are a bit more convincing than those.

      • tmpod@lemmy.pt
        1·
        3 years ago

        I do see what you mean. I’m not sure why it’s important to have different datatypes for structure/order and not for other things. You could have different syntaxes for volumes, distances, and coefficients. You don’t need a separate data-type for each type of quantity, but you could. It would make certain types of algorithms more readable.

        Those would be units, not actual data collections/structures, like lists, tuples and so on. They are different things. It wouldn’t make sense to have a type for each unit, and it would also be unfeasible to do so. Having different core types for order, structrue, relation and math sets is important, however.

        print(id(True))

        9476448

        print(id(1))

        9788608

        In what sense is True an alias for 1? It’s a boolean not an integer. It really is a different data-type.

        You’re right, I misremembered it. But, booleans are in fact subclasses of integers.

        It would be more reasonable to remove integers and just use floats. Those two are much more similar.

        No, it would not be reasonable. Not only are floats a bad replacement for ints, but I’d argue it would go against Python’s principle of being simple but highly flexible and easy to understand. As I’ve stated, having these different primitive types helps a lot when trying to convey intention.

        It’s an interesting way of thinking, and has this whole “pythonic” philosophy, experimenting with different ways of thinking.

        Yeah. I also have to say that the term “pythonic” is thrown around a lot and it has a very foggy definition. The Zen of Python (import this) is equally as often cited and, while it certainly provides some nice guidelines, it mustn’t be taken word by word. In many ways, the Python language doesn’t comply with its Zen, in some situations for good, and others for not so good.

        Thanks for sharing. As I said these are not the usual explanations I’ve found on the internet. Your explanations are a bit more convincing than those.

        You’re welcome! I’ve found this exchange rather fruitful as it hopefully shed some light on the matter and made me have to take a step back and think clearly about my reasoning. It’s great to have these kinds of discussions and have your views challenged :3

    • tmpod@lemmy.pt
      0·
      3 years ago

      Also, to add on to that, if you wish an even simpler language, with really just one collection and structure type, look at Lua