435,481 Members | 3,170 Online
Need help? Post your question and get tips & solutions from a community of 435,481 IT Pros & Developers. It's quick & easy.

# Lists and Tuples

 P: n/a I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other? Jeff Jul 18 '05 #1
42 Replies

 P: n/a Jeff Wagner writes: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other? Try this with a list: a = [1, 2, 3, 4, 5] a[3] = 27 print a Then try it with a tuple. Jul 18 '05 #2

 P: n/a In article <7x************@ruckus.brouhaha.com>, Paul Rubin wrote: Try this with a list: a = [1, 2, 3, 4, 5] a[3] = 27 print a Then try it with a tuple. That's true, but another answer is: you should use tuples for short sequences of diverse items (like the arguments to a function). You should use lists for longer sequences of similar items. -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science Jul 18 '05 #3

 P: n/a On 04 Dec 2003 21:31:12 -0800, Paul Rubin wrotf: Jeff Wagner writes: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other? Try this with a list: a = [1, 2, 3, 4, 5] a[3] = 27 print aThen try it with a tuple. That's because a tuple is immutable and a list is mutable but what else? I guess I said everything I tried with a tuple worked with a list ... not mentioning I didn't try to break the immutable/mutable rule I was aware of. Besides trying to change a tuple, I could cut it, slice and dice it just like I could a list. They seemed to have the same built-in methods, too. From what I can see, there is no reason for me to ever want to use a tuple and I think there is something I am missing. Why would Guido go to all the effort to include tuples if (as it appears) lists are just as good but more powerful ... you can change the contents of a list. Jeff Jul 18 '05 #4

 P: n/a On Fri, Dec 05, 2003 at 05:19:33AM +0000, Jeff Wagner wrote: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other? What's the difference? import sets sets.Set(dir(list)).difference(sets.Set(dir(tuple) )) Set(['sort', 'index', '__delslice__', 'reverse', 'extend', 'insert', '__setslice__', 'count', 'remove', '__setitem__', '__iadd__', 'pop', '__delitem__', 'append', '__imul__']) ;) -Andrew. Jul 18 '05 #5

 P: n/a Jeff Wagner wrote: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other? Jeff Here's the biggie: association = {} somevals = 1,2,6,'a' association[somevals] = 13 vs. association = {} somevals = [1,2,6,'a'] association[somevals] = 13 -Scott David Daniels Sc***********@Acm.Org Jul 18 '05 #6

 P: n/a Jeff Wagner fed this fish to the penguins on Thursday 04 December 2003 21:19 pm: tuple. So, what's the difference and why choose one over the other? A tuple can be the key for a dictionary, a list can't. Not sure of a tuple containing a list, though... -- ================================================== ============ < wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < wu******@dm.net | Bestiaria Support Staff < ================================================== ============ < Bestiaria Home Page: http://www.beastie.dm.net/ < Home Page: http://www.dm.net/~wulfraed/ < Jul 18 '05 #7

 P: n/a David Eppstein writes: That's true, but another answer is: you should use tuples for short sequences of diverse items (like the arguments to a function). You should use lists for longer sequences of similar items. I disagree. You should use a tuple when you wish to not change the contents once you have constructed the sequence, and otherwise you should use a list. Using a tuple can make your code clearer by letting the reader know from the beginning that the contents won't be changing. Fredrik Lundh actually called me names a couple years back for asserting this, but Python luminary (and rude fellow) or not, he is dead wrong. You don't have to take my word for it, though, since Python itself uses tuples in this manner, in the form of the container used for excess arguments (excess arguments certainly don't have to be short, and they are generally homogeneous, not heterogeneous), and Python Mega Widgets (for example) is littered with code that looks like: optiondefs = ( ('initwait', 500, None), # milliseconds ('label_background', 'lightyellow', None), ('label_foreground', 'black', None), ('label_justify', 'left', None), ('master', 'parent', None), ('relmouse', 'none', self._relmouse), ('state', 'both', self._state), ('statuscommand', None, None), ('xoffset', 20, None), # pixels ('yoffset', 1, None), # pixels ('hull_highlightthickness', 1, None), ('hull_highlightbackground', 'black', None), ) In the above case we see tuples being used both as records *and* as an arbitrary-length sequence of homogenious elements. Why is a tuple being used in the latter case, rather than a list? Because the sequence isn't going to be modified. |>oug Jul 18 '05 #8

 P: n/a On Thu, 04 Dec 2003 21:45:23 -0800, David Eppstein wrote: In article <7x************@ruckus.brouhaha.com>, Paul Rubin wrote: Try this with a list: a = [1, 2, 3, 4, 5] a[3] = 27 print a Then try it with a tuple.That's true, but another answer is: you should use tuples for shortsequences of diverse items (like the arguments to a function). Youshould use lists for longer sequences of similar items. I'm curious what you're getting at. I.e., what does diversity or similarity have to do with the choice? Is that an aesthetic thing? (In which case 'should' should be qualified a bit, IWT ;-) Or what am I missing? Regards, Bengt Richter Jul 18 '05 #9

 P: n/a X-Draft-From: ("comp.lang.python" 285349) To: bo**@oz.net (Bengt Richter) Subject: Re: Lists and Tuples References: <7x************@ruckus.brouhaha.com> Fcc: |rcvstore +articles From: Douglas Alan --text follows this line-- bo**@oz.net (Bengt Richter) writes: On Thu, 04 Dec 2003 21:45:23 -0800, David Eppstein wrote: That's true, but another answer is: you should use tuples for short sequences of diverse items (like the arguments to a function). You should use lists for longer sequences of similar items. I'm curious what you're getting at. I.e., what does diversity or similarity have to do with the choice? Nothing really, except by idiom. When people use "should" here, I think they are over-generalizing. Most of the time, records (short and heterogenious) are used in a read-only fashion, and long homogenous sequences are used in a read-write fashion. But when people characterize this tendency with a "should", I think they are making a thinko. There are times when you need to modify a record and consequently might use a dictionary or list, rather than a tuple, and there are also times when you will never want to modify a long, homogenous sequence, in which case many people would find it more elegant to use a tuple than to use a list. The reason for the "should" is probably because, I imagine, Guido had in mind mostly multiple return values from function, and the like, when he put tuples into the language. |>oug Jul 18 '05 #10

 P: n/a Jeff Wagner wrote: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other? According to the Python FAQ: ------------------------------------------------------------------------ 4.15 Why are there separate tuple and list data types? Lists and tuples, while similar in many respects, are generally used in fundamentally different ways. Tuples can be thought of as being similar to Pascal records or C structs; they're small collections of related data which may be of different types which are operated on as a group. For example, a Cartesian coordinate is appropriately represented as a tuple of two or three numbers. Lists, on the other hand, are more like arrays in other languages. They tend to hold a varying number of objects all of which have the same type and which are operated on one-by-one. For example, os.listdir('.') returns a list of strings representing the files in the current directory. Functions which operate on this output would generally not break if you added another file or two to the directory. Tuples are immutable, meaning that once a tuple has been created, you can't replace any of its elements with a new value. Lists are mutable, meaning that you can always change a list's elements. Only immutable elements can be used as dictionary keys, and hence only tuples and not lists can be used as keys. http://www.python.org/doc/faq/genera...ist-data-types ------------------------------------------------------------------------ Of course, this information will prevent neither flame wars, nor you from using them how you wish (within the boundaries of the language). However you choose to use them, just be clear and consistent. Peace, Joe Jul 18 '05 #11

 P: n/a Jeff Wagner wrote in news:f5********************************@4ax.com: From what I can see, there is no reason for me to ever want to use a tuple and I think there is something I am missing. Why would Guido go to all the effort to include tuples if (as it appears) lists are just as good but more powerful ... you can change the contents of a list. The most practical difference (if you don't need to modify the contents) is that tuples can be used as dictionary keys, but lists cannot. There is a minor performance difference, in particular tuples will take less memory so if you have a few million of them kicking around your application you might notice the difference. However, as other posters have suggested the best way to look at it is often to use tuples when you have a fixed number of objects, possibly of different types, e.g. a database record. When you have a variable number of objects (usually of the same type, or supporting a similar interface) then a list if obviously better. If you have a variable number of groups of objects, then a list of tuples seems to fit best. In any of these cases you could use a list in place of the tuple, but the distinction can help keep things clear. Bottom line: If you are primarily reading the sequence using constant indices, then use a tuple. If the code starts looking messy then consider defining a class to replace the tuples and using fieldnames instead of constant indices. If you need to use the object as a dictionary key, or if you have reason to be concerned about memory use (because there are a lot of them) use a tuple. Otherwise use a list. -- Duncan Booth du****@rcp.co.uk int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3" "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure? Jul 18 '05 #12

 P: n/a Douglas Alan wrote: I disagree. You should use a tuple when you wish to not change the contents once you have constructed the sequence, and otherwise you should use a list. Fredrik Lundh actually called me names a couple years back for asserting this, but Python luminary (and rude fellow) or not, he is dead wrong. I'm never dead wrong. Guido van Rossum, "State of the Python Union", March 2003: http://www.python.org/doc/essays/ppt.../pycon2003.ppt ... + It's a matter of user education + Example: lists vs. tuples this is often misrepresented as "tuple are readonly lists", which is *wrong* use cases are quite different *but*... tuples also usable as readonly lists ... I expect an apology. Jul 18 '05 #13

 P: n/a Dennis Lee Bieber writes: Jeff Wagner fed this fish to the penguins on Thursday 04 December 2003 21:19 pm: tuple. So, what's the difference and why choose one over the other? A tuple can be the key for a dictionary, a list can't. Not sure of a tuple containing a list, though... Nope. A tuple is hashable iff all of its elements are. Cheers, mwh -- Now this is what I don't get. Nobody said absolutely anything bad about anything. Yet it is always possible to just pull random flames out of ones ass. -- http://www.advogato.org/person/vicio....html?start=60 Jul 18 '05 #14

 P: n/a On Fri, 5 Dec 2003 16:59:57 +1100, Andrew Bennetts wrote: On Fri, Dec 05, 2003 at 05:19:33AM +0000, Jeff Wagner wrote: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other?What's the difference? import sets sets.Set(dir(list)).difference(sets.Set(dir(tuple) ))Set(['sort', 'index', '__delslice__', 'reverse', 'extend', 'insert','__setslice__', 'count', 'remove', '__setitem__', '__iadd__', 'pop','__delitem__', 'append', '__imul__']);)-Andrew. I like that--ask a simple question, get a simple answer. Why can't they all be so straightforward. :-) --dang Jul 18 '05 #15

 P: n/a In article , Jeff Wagner wrote: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other? Jeff The big difference is that tuples (because they are immutable) can be used as dictionary keys. So, if you are going to use it as a key, it's got to be a tuple. If you're going to want to add/delete/change items in it, it's got to be a list. If you will never change it, but have no syntatic constraint forcing it to be immutable, you can pick whichever turns you on. From a stylistic point of view, I tend to think of tuples when I need to bundle up a collection of related items (such as a function returning multiple items). Lists make me think of number of the same kind of item. Jul 18 '05 #16

 P: n/a Joe Francia wrote: For example, a Cartesian coordinate is appropriately represented as a tuple of two or three numbers. I would agree if you're explicitly talking about 2-space or 3-space. But if you're dealing with higher-order geometries, then a coordinate becomes an N-vector and now it starts to feel more like a list than a tuple. I can't put any rigorous argument behind that, it's just what (to me) feels right. Jul 18 '05 #17

 P: n/a I just stumbled upon an interesting tuple/list dichotomy. The new isinstance() function can take a tuple (but not a list) as its second argument. Why? Logically, it should take any sequence. The operation it's doing is essentially: for aType in sequence: if isinstance (thing, aType): return True return False I don't see any reason it should reject a list, but it does: isinstance (1, [str, int]) Traceback (most recent call last): File "", line 1, in ? TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types This is documented, but it still seems strange. Why go out of your way to reject a list when a list is really a perfectly reasonable thing to pass in that context? Same deal with issubclass(). Jul 18 '05 #18

 P: n/a In article , bo**@oz.net (Bengt Richter) wrote:On Thu, 04 Dec 2003 21:45:23 -0800, David Eppstein wrote:That's true, but another answer is: you should use tuples for shortsequences of diverse items (like the arguments to a function). Youshould use lists for longer sequences of similar items.I'm curious what you're getting at. I.e., what does diversity orsimilarity have to do with the choice? Is that an aesthetic thing?(In which case 'should' should be qualified a bit, IWT ;-)Or what am I missing? To me, it's a distinction without a difference. Tuples *act* like immutable sequences, and I use them that way. I don't know, though, that I won't get caught some day. Python 3.3 (#22, Jul 29 2013, 14:34:42) [MSC v.9200 96 bit (Intel)] on win96 Type "help", "copyright", "credits" or "license" for more information. t = (1,4,7,34,789) Traceback (most recent call last): File "", line 1, in ? HomogeneityError: tuple elements are not diverse Regards. Mel. Jul 18 '05 #19

 P: n/a In article , Roy Smith wrote: The new isinstance() function can take a tuple (but not a list) as its second argument. Why? Logically, it should take any sequence. What should it do if the second argument is a type object that is also iterable? E.g. suppose that iter(bool) produced the sequence True, False. ... -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science Jul 18 '05 #20

 P: n/a On Fri, 5 Dec 2003 16:59:57 +1100, Andrew Bennetts wrote: On Fri, Dec 05, 2003 at 05:19:33AM +0000, Jeff Wagner wrote: I've spent most of the day playing around with lists and tuples to get a really good grasp on what you can do with them. I am still left with a question and that is, when should you choose a list or a tuple? I understand that a tuple is immutable and a list is mutable but there has to be more to it than just that. Everything I tried with a list worked the same with a tuple. So, what's the difference and why choose one over the other?What's the difference? Items in lists and not in tuples: import sets sets.Set(dir(list)).difference(sets.Set(dir(tuple) ))Set(['sort', 'index', '__delslice__', 'reverse', 'extend', 'insert','__setslice__', 'count', 'remove', '__setitem__', '__iadd__', 'pop','__delitem__', 'append', '__imul__']);)-Andrew. And Items in tuples and not in lists: sets.Set(dir(tuple)).difference(sets.Set(dir(list) )) Set(['__getnewargs__']) Items in both tuples and lists: sets.Set(dir(tuple)).intersection(sets.Set(dir(lis t))) Set(['__getslice__', '__str__', '__getattribute__', '__rmul__', '__lt__', '__init__', '__setattr__', '__reduce_ex__', '__new__', '__contains__', '__class__', '__doc__', '__len__', '__mul__', '__ne__', '__getitem__', '__reduce__', '__iter__', '__add__', '__gt__', '__eq__', '__delattr__', '__le__', '__repr__', '__hash__', '__ge__']) Maybe someone could tell me how and/or when __getnewargs__ is used? _Ronald Adam Jul 18 '05 #21

 P: n/a Jeff Wagner wrote: On 04 Dec 2003 21:31:12 -0800, Paul Rubin wrotf:Jeff Wagner writes:I've spent most of the day playing around with lists and tuples toget a really good grasp on what you can do with them. I am stillleft with a question and that is, when should you choose a list or atuple? I understand that a tuple is immutable and a list is mutablebut there has to be more to it than just that. Everything I triedwith a list worked the same with a tuple. So, what's the differenceand why choose one over the other? Try this with a list: a = [1, 2, 3, 4, 5] a[3] = 27 print aThen try it with a tuple. That's because a tuple is immutable and a list is mutable but what else? I guess I said everything I tried with a tuple worked with a list ... not mentioning I didn't try to break the immutable/mutable rule I was aware of. Besides trying to change a tuple, I could cut it, slice and dice it just like I could a list. They seemed to have the same built-in methods, too. From what I can see, there is no reason for me to ever want to use a tuple and I think there is something I am missing. Why would Guido go to all the effort to include tuples if (as it appears) lists are just as good but more powerful ... you can change the contents of a list. Should you wish to use a sequence as the key for a dictionary, then a tuple would be the choice. Colin W. Jeff Jul 18 '05 #22

 P: n/a Ron Adam wrote: Maybe someone could tell me how and/or when __getnewargs__ is used? PEP 307 ("Extensions to the pickle protocol") might be somewhat helpful: http://www.python.org/peps/pep-0307.html Jul 18 '05 #23

 P: n/a Douglas Alan wrote: Fredrik Lundh actually called me names a couple years back for asserting this, but Python luminary (and rude fellow) or not, he is dead wrong. I'm never dead wrong. You were dead wrong to insult me in a debate over subtle programming aesthetics, where my opinion is just as well-founded as anyone's. I actually had to dig up the thread that has caused you such grief over the years. as expected, you spent that thread attacking everyone who dis- agreed with you, misrepresented other people's arguments, referred to implementation artifacts and design mistakes as "proof", and used the same muddled thinking as you've shown in this thread. heck, Tim even introduced the term "douglas-sequences" in contrast to "python-sequences" in order to make any sense of what you were arguing about that time. not the kind of behaviour I'd expect from anyone who wants to be taken seriously. two years later, you haven't learned a thing; that's pretty tragic. Jul 18 '05 #24

 P: n/a On Fri, 5 Dec 2003 11:10:34 -0600, Skip Montanaro wrote: Generally, choose between tuples and lists based upon your data. Insituations where you have a small, fixed collection of objects of possiblydiffering types, use a tuple. In situations where have a collection ofobjects of uniform type which might grow or shrink, use a list. Forexample, an address might best be represented as a tuple: itcs = ("2020 Ridge Avenue", "Evanston", "IL", "60201") caffe_lena = ("47 Phila Street", "Saratoga Springs", "NY", "12866")Though all elements are actually strings, they are conceptually differenttypes. It probably makes no sense to define itcs as Some of my confusion derived from these semantic issues. We are strongly typed and when the list/tuple distinction starts to be talked with the words "types"," homogenous" , "heterogenous" in close proximity - we, on the receiving end, will .... I think the potential misdriection is obvious from your explanation above. "Type" is not normally an ambiguous word. It seems to me that an explanation would stress, upfront, that in fact homogenous.hetereogenous in this context is at an abstract level, and unrelated to type,as such and as your example illustrates. Or else, why does the word "type" need to occur at all, other than perhaps to explain, explicitily, it is not of relevance Rather than in a way that implies that it is. This is a question really. Though not properly phrased as one. Because I fear I am still missing something. Art Jul 18 '05 #25

 P: n/a Arthur wrote: "Type" is not normally an ambiguous word. really? in my experience, "type" and "object" are about as ambiguous as words can get, especially when you're talking about Python. Jul 18 '05 #26

 P: n/a On Sun, 7 Dec 2003 15:09:48 +0100, "Fredrik Lundh" wrote: Arthur wrote: "Type" is not normally an ambiguous word.really? in my experience, "type" and "object" are about as ambiguousas words can get, especially when you're talking about Python. I am sure you are right. On faith. Though its not particularly helpful. Art Jul 18 '05 #27

 P: n/a On Sun, 07 Dec 2003 15:07:58 GMT, Arthur wrote: On Sun, 7 Dec 2003 15:09:48 +0100, "Fredrik Lundh" wrote:Arthur wrote: "Type" is not normally an ambiguous word.really? in my experience, "type" and "object" are about as ambiguousas words can get, especially when you're talking about Python.I am sure you are right. On faith. Though its not particularlyhelpful.Art Or else I can rephrase my question. Having learned that type and object are highly ambiguous words, why do we would tend to use them when wanting to clarify list/tuple distinctions. Art Jul 18 '05 #28

 P: n/a "Fredrik Lundh" writes: as expected, you spent that thread attacking everyone who dis- agreed with you, misrepresented other people's arguments, referred to implementation artifacts and design mistakes as "proof", and used the same muddled thinking as you've shown in this thread. heck, Tim even introduced the term "douglas-sequences" in contrast to "python-sequences" in order to make any sense of what you were arguing about that time. not the kind of behaviour I'd expect from anyone who wants to be taken seriously. Your characterization of the past debate is not only a self-serving caricature, but it is disingenuous as well. I never attacked or misrepresented anyone -- I merely disagreed with them. Only you attacked anyone, Fredrik. As you chose to do again. And misrepresent. two years later, you haven't learned a thing; that's pretty tragic. And you still resort to insults, rather than reason. Yes, tragic, especially for someone who is apparently an icon of the Python community. And speaking of "proof" for one's point -- you never provided a single iota of evidence, much less proof, for the idea that tuples should only be used as records, except for that you and Guido say so. |>oug Jul 18 '05 #29

 P: n/a In article , Fredrik Lundh wrote:Arthur wrote: "Type" is not normally an ambiguous word.really? in my experience, "type" and "object" are about as ambiguousas words can get, especially when you're talking about Python. Hrm. I see your point, but I also think it's fairly easy to get people to agree on definitions for "type" and "object" within the context of a discussion. From my POV, the ambiguity comes from layering on additional meanings beyond that supported by the C API. -- Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. Jul 18 '05 #30

 P: n/a Aahz wrote: From my POV, the ambiguity comes from layering on additional meanings beyond that supported by the C API. what C API? (duck) Jul 18 '05 #31

 P: n/a Fredrik Lundh wrote: as expected, you spent that thread attacking everyone who dis- agreed with you, misrepresented other people's arguments, referred to implementation artifacts and design mistakes as "proof", and used the same muddled thinking as you've shown in this thread. So you're saying he's a news commentator for Fox News? ;>) Jul 18 '05 #32

 P: n/a Quoth Arthur : | On Fri, 5 Dec 2003 11:10:34 -0600, Skip Montanaro | wrote: |> Generally, choose between tuples and lists based upon your data. In |> situations where you have a small, fixed collection of objects of possibly |> differing types, use a tuple. In situations where have a collection of |> objects of uniform type which might grow or shrink, use a list. For |> example, an address might best be represented as a tuple: |> |> itcs = ("2020 Ridge Avenue", "Evanston", "IL", "60201") |> caffe_lena = ("47 Phila Street", "Saratoga Springs", "NY", "12866") |> |> Though all elements are actually strings, they are conceptually different |> types. It probably makes no sense to define itcs as | "Type" is not normally an ambiguous word. It seems to me that an | explanation would stress, upfront, that in fact | homogenous.hetereogenous in this context is at an abstract level, and | unrelated to type,as such and as your example illustrates. | | Or else, why does the word "type" need to occur at all, other than | perhaps to explain, explicitily, it is not of relevance Apologies in advance if someone has already said this. It may be a little too algebraic for the Python world, but for me the difference can be expressed like this - n > 0 or m < sizeof(a) and conceptual_type(a) == conceptual_type(a[n:m]) If that holds, then the conceptual type is naturally implemented with a list. I'm not sure it's right to say that the elements of a tuple are necessarily of conceptually different types, distinguished only by their positiion. But the point is that they _are_ distinguished by position (so a slice is not substitable with its source.) Of course this still relies on a notion of conceptual type that can't be expressed literally in Python, but it's a healthy one. Donn Cave, do**@drizzle.com Jul 18 '05 #33

 P: n/a Douglas Alan wrote: mw*****@the-wire.com (Mel Wilson) writes: To me, it's a distinction without a difference. Tuples*act* like immutable sequences, and I use them that way. Idon't know, though, that I won't get caught some day. You'll be fine. The only thing you have to watch out for is that some rude folks here might call you names. That would add some spice to Python's error messages... Python 3.7 (#1, Sep 31 2007, 14:19:37) [GCC 5.6.7] on slartibartfast Type "help", "copyright", "credits" or "license" for more information. t = (1, 3, 77, 654, 8) Traceback (most recent call last): File "", line 1, in ? HumiliationError: The programmer is a pink-faced baboon (tuple used where list would be more appropriate) -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg Jul 18 '05 #34

 P: n/a Ron Adam wrote: Items in lists and not in tuples: .... And Items in tuples and not in lists: And chicks on blocks but not on clocks... -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg Jul 18 '05 #35

 P: n/a In article , "Greg Ewing (using news.cis.dfn.de)" wrote: Douglas Alan wrote: mw*****@the-wire.com (Mel Wilson) writes: To me, it's a distinction without a difference. Tuples*act* like immutable sequences, and I use them that way. Idon't know, though, that I won't get caught some day. You'll be fine. The only thing you have to watch out for is that some rude folks here might call you names. That would add some spice to Python's error messages... Python 3.7 (#1, Sep 31 2007, 14:19:37) [GCC 5.6.7] on slartibartfast Type "help", "copyright", "credits" or "license" for more information. >>> t = (1, 3, 77, 654, 8) Traceback (most recent call last): File "", line 1, in ? HumiliationError: The programmer is a pink-faced baboon (tuple used where list would be more appropriate) In MVP (Microsoft Visual Python), the "auto-correct" function would just silently change the ()'s to []'s as you typed them. If you tried to change them back, clippy would pop up on the screen and say, "You seem to be trying to do something un-pythonic. Would you like some assistance?". If you tried to make clippy go away, it would offer to "install this critical security patch immediately". Jul 18 '05 #36

 P: n/a "Greg Ewing (using news.cis.dfn.de)" writes: Douglas Alan wrote: You'll be fine. The only thing you have to watch out for is that some rude folks here might call you names. That would add some spice to Python's error messages... Python 3.7 (#1, Sep 31 2007, 14:19:37) [GCC 5.6.7] on slartibartfast Type "help", "copyright", "credits" or "license" for more information. >>> t = (1, 3, 77, 654, 8) Traceback (most recent call last): File "", line 1, in ? HumiliationError: The programmer is a pink-faced baboon (tuple used where list would be more appropriate) Hmmm, could I catch the exception and then continue on anyway? Kind of like casting away const in C++? |>oug Jul 18 '05 #37

 P: n/a On Mon, 08 Dec 2003 16:36:05 +1300 "Greg Ewing (using news.cis.dfn.de)" wrote: That would add some spice to Python's error messages... Python 3.7 (#1, Sep 31 2007, 14:19:37) [GCC 5.6.7] on slartibartfast Type "help", "copyright", "credits" or "license" for more information. >>> t = (1, 3, 77, 654, 8) Traceback (most recent call last): File "", line 1, in ? HumiliationError: The programmer is a pink-faced baboon (tuple used where list would be more appropriate) Hmmm..Sep 31? Should I file a bug report? ;o) John Jul 18 '05 #38

 P: n/a On Sun, 07 Dec 2003 22:42:17 -0500, Roy Smith wrote: In MVP (Microsoft Visual Python), the "auto-correct" function would justsilently change the ()'s to []'s as you typed them. If you tried tochange them back, clippy would pop up on the screen and say, "You seemto be trying to do something un-pythonic. Would you like someassistance?". If you tried to make clippy go away, it would offer to"install this critical security patch immediately". Give some credit. The unitype system will have been inplemented by then. One's decoded DNA sequence will be accessed (some people thought web services would be a bust, back in aught 3), with reference to which, one's intentions are determined. Programming now called "hinting". CH4E. Art Jul 18 '05 #39

 P: n/a On 7 Dec 2003 11:02:38 -0500, aa**@pythoncraft.com (Aahz) wrote: In article ,Fredrik Lundh wrote:Arthur wrote: "Type" is not normally an ambiguous word.really? in my experience, "type" and "object" are about as ambiguousas words can get, especially when you're talking about Python. I actually see the point also, with direct relevance to Lists and Tuple tutorial semantics, to the extent that I am confused whether instances of different classes are of the same "type". I have considered no. By inheriting from object and creating something new from it I am creating a custom type. I thought. I think this impression comes from my little experinece with other languages. And since the way I use lists are to group instances of different classes, which may have nothing in common other than a single method of the same name, I have considered my lists to be of heterogenous type. Which is why I have been confused by the language to describe the prototypical use of lists. Art Hrm. I see your point, but I also think it's fairly easy to get peopleto agree on definitions for "type" and "object" within the context of adiscussion. From my POV, the ambiguity comes from layering on additionalmeanings beyond that supported by the C API. Jul 18 '05 #40

 P: n/a >>>>> "Greg" == Greg Ewing <(using news.cis.dfn.de)" > writes: Greg> Ron Adam wrote: Items in lists and not in tuples: Greg> ... And Items in tuples and not in lists: Greg> And chicks on blocks but not on clocks... Through three cheese trees, three free fleas flew... Skip Jul 18 '05 #41

 P: n/a John La Rooy wrote: Hmmm..Sep 31? Should I file a bug report? ;o) You're failing to take into account the (highly controversial) International Calendar Reform of 2006, which gave all months the same number of days. Python was, of course, the first language to have its datetime module updated to conform with the new standard. (Microsoft Java++#.NET was updated too, but in a subtly incompatible way -- all their months were given 30 days instead.) -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg Jul 18 '05 #42

 P: n/a Greg Ewing wrote: Hmmm..Sep 31? Should I file a bug report? ;o) You're failing to take into account the (highly controversial) International Calendar Reform of 2006, which gave all months the same number of days. Python was, of course, the first language to have its datetime module updated to conform with the new standard. (Microsoft Java++#.NET was updated too, but in a subtly incompatible way -- all their months were given 30 days instead.) it's well known (at least to insiders) that the bug in MSJPCS.NET was the reason for the reform. a "32 days is better for computers" alternative was brought forward by the usual suspects (IBM, Sun, etc, plus a bunch of bloggers hellbent on teaching Dave Winer a lesson), but was, as usual, largely ignored by everyone else. 31 might be due to a EU translation error, but I'm not sure. I also hear that the french edition of the standard uses 13 days. Jul 18 '05 #43

### This discussion thread is closed

Replies have been disabled for this discussion.