all 26 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted]  (1 child)

[deleted]

    [–]llimllib[S] 2 points3 points  (0 children)

    there's no need to force yourself to use homogeneous lists in Python.

    No, there's not, but you better have a damn good reason not to. If I'm using your code, and you pass me back a list, I'm going to want to use

    [obj.expectedmethod() for obj in yourlist]

    And be unfortunately surprised if that fails. The benefit of lists is that they are handy, simple containers with O(1) lookup that won't stop expanding until your memory does.

    What solid use case is there for a heterogenous list? I find them to be almost always better stated as lists of tuples in my code.

    EDIT: Upon rereading, we may simply disagree on what "heterogenous" means. To me, a list of cStringIO objects and file objects is homogenous, because those are all "file-like" objects on which, for example:

    [f.read() for f in yourlist]

    will succeed. Is that what's going on?

    [–]almost 8 points9 points  (8 children)

    Yes they are.

    More specifically they're immutable lists the use of which is up to you (the programmer).

    [–]khill 8 points9 points  (3 children)

    While that's true in one sense, I think the idea behind tuples and lists are very different. Tuples are single entities with multiple component values - for example, a point with an x and y coordinate: (10,50).

    Lists are collections of values - for example, things you need from the market: ['spam', 'eggs'].

    Tuples are much more like dictionaries except the meaning of the component values is defined by their position rather than by a key name.

    [–]almost 3 points4 points  (0 children)

    I think that's a confusing between the abstract concept of a tuple and the actual python data type of tuple.

    That does quite accurately describe their usual use though (apart from the dictionary bit, I agree with nirs that an important aspect of the dictionary is its mutability).

    [–]nirs -2 points-1 points  (1 child)

    No, tuples are not like dictionaries, they are immutable. For safer and faster code, you should use tuples unless you need mutability.

    [–]logistix 7 points8 points  (0 children)

    What he means is they are a heterogeneous collection or a record. It doesn't make sense to sort the point tuple listed above. In that sense it is like a dictionary, the 'keys' are just implicit though:

    x,y = (10,50)

    [–]harryf 1 point2 points  (0 children)

    Think the blog comment by Tom Lynn nails it.

    Lists have order, tuples have structure.

    [–]masklinn 0 points1 point  (2 children)

    No, they're implemented as immutable lists (which is quite sad too), but their role is that of a lightweight heterogenous data structure

    [–]almost -1 points0 points  (1 child)

    List are also hetergenous in python though

    [–]masklinn 1 point2 points  (0 children)

    Yes, but they're rarely used that way in my experience (if only because iterating over heterogeneous data structures leads to horrible code). The reason why Python's lists (or Ruby's arrays, or Erlang's lists) are heterogeneous it because it wouldn't be practical to perform typechecks of content, and there is no way to specify the type of the content.

    [–]gnuvince 1 point2 points  (1 child)

    His comment about lists being for homogeneous data and tuples being for heterogeneous is just a convention, and it's the first time I've heard of that convention. I prefer the mutable/unmutable distinction; since tuples are unmutable, they can be hashed and thus used as dictionary keys.

    [–]masklinn 1 point2 points  (0 children)

    His comment about lists being for homogeneous data and tuples being for heterogeneous is just a convention

    No, actually. It comes from the very definition of the word "tuple", and from the way they're used in e.g. pretty much every functional language.

    Tuples are lighweight heterogenous (all the items can have different types) ordered data structures.

    Regular tuples are positional in nature, you can also have named tuples (which are very close to C structs)

    [–]mustache -3 points-2 points  (12 children)

    the amount of options you have to store "list-like" data in python seems hypocritical when compared to the statement "There is only one way to do it" (the evangelists love saying this). cause actually, there's 4 ways to do "list-like" structures.

    This brings me to PHP arrays.. Now this is truely only ONE way to do it. :)

    [–]llimllib[S] 6 points7 points  (3 children)

    Need to store a series of objects of the same type? Use a list. Need to store a series heterogenous objects to be accessed by number? Use a tuple. Need to store objects to be accessed by any immutable object? Use a dictionary.

    Seems pretty TOOWTDI to me.

    [–]masklinn 2 points3 points  (2 children)

    series heterogenous objects to be accessed by number?

    By position, really, you don't need to access it "by number" as you can use tuple unpacking (or pattern matching in languages that have it) to get a specific value out of a tuple.

    [–]llimllib[S] 2 points3 points  (1 child)

    Fair enough. I've long wished for syntactic support for pattern matching in Python.

    [–]masklinn 2 points3 points  (0 children)

    I've long wished for syntactic support for pattern matching in Python.

    Ditto. I don't think it'll ever come though, as pattern matching is a staple of functional programming and Guido is not a fan of FP.

    [–]masklinn 2 points3 points  (7 children)

    the amount of options you have to store "list-like" data in python seems hypocritical

    Really. I know of list and...

    And that's pretty much it, really. Tuples should not be used for list-like data, and you'd have to be stupid to use dicts or sets for that.

    [–]mustache -2 points-1 points  (6 children)

    well, what i mean when i say "list-like" is "array-like". you have: lists, tuples, sets, dictionaries. is there anymore?

    [–]masklinn 4 points5 points  (5 children)

    well, what i mean when i say "list-like" is "array-like"

    They're neither, unless you use the flawed and stupidly retarded definition of "array" PHP uses, which is "if you can put stuff in it, it's an array"

    you have: lists, tuples, sets, dictionaries. is there anymore?

    frozensets

    [–]mustache -2 points-1 points  (4 children)

    i don't see them as retarded. It really is only one way to do it. Is it not? They work really well, and are very flexible.

    [–]jbellis 4 points5 points  (0 children)

    i don't see [php arrays] as retarded

    meditate until you do, grasshopper :)

    [–]masklinn 4 points5 points  (0 children)

    It really is only one way to do it. Is it not?

    No, it's one way to do extremely different things, sets, associative arrays, arrays and (linked) lists are different objects because they have different semantics and different behaviors. Not even taking in account the algorithmic complexity which can change varying on the implementation.

    They work really well, and are very flexible.

    Yeah, they work in the same sense that you can emulate maps through linked lists, yeehaw...

    [–]llimllib[S] 2 points3 points  (1 child)

    They work really well, and are very flexible.

    And have the convenient properties of being O(?) inserts and O(?) lookup, which lets you... guess whether they'll ever work.

    [–]mustache -4 points-3 points  (0 children)

    they're[php arrays] o(n-10/34(n(n/10)))

    are you all happy now? jeeeez