Re: tuple.index() and tuple.count()

On Jun 23, 3:13 pm, [EMAIL PROTECTED] wrote: > never mind... a coworker pointed me to this > > http://bugs.python.org/issue1696444 > > apparently they're there in py3k... and 2.6 -- http://mail.python.org/mailman/listinfo/python-list

Re: tuple.index() and tuple.count()

never mind... a coworker pointed me to this http://bugs.python.org/issue1696444 apparently they're there in py3k... -- http://mail.python.org/mailman/listinfo/python-list

tuple.index() and tuple.count()

Before the inevitable response comes, let me assure you I've read through the posts from Guido about this. 7 years ago Guido clearly expressed a displeasure with allowing these methods for tuple. Let me lay out (in a fresh way) why I think we should reconsider. 1) It's counterintuitive to exclude

Re: tuple.index()

"Nick Maclaren" <[EMAIL PROTECTED]> wrote: > "Hendrik van Rooyen" <[EMAIL PROTECTED]> writes: > |> When I looked at the above, I went "tilt" - > > Yes, you are confused :-) Neither the agents nor strings take the > other as 'arguments', but are effectively methods of the I/O object. > Let's co

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Hendrik van Rooyen" <[EMAIL PROTECTED]> writes: |> "Nick Maclaren" <[EMAIL PROTECTED]> wrote: |> |> > Not at all. I didn't say that they came in pairs. Consider: |> > |> > [str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...] |> > |> > See Algol 68

Re: tuple.index()

In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> writes: |> |> > Not at all. I didn't say that they came in pairs. Consider: |> > |> > [str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...] |> |> That's homogeneous. Any item of the list can be |> either a string or an agent

Re: tuple.index()

"Nick Maclaren" <[EMAIL PROTECTED]> wrote: > Not at all. I didn't say that they came in pairs. Consider: > > [str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...] > > See Algol 68 for an example of this. When I looked at the above, I went "tilt" - If you had no a priori knowledge

Re: tuple.index()

Nick Maclaren wrote: > Not at all. I didn't say that they came in pairs. Consider: > > [str1, str2, agent1, str3, agent2, agent3, agent4, str4, ...] That's homogeneous. Any item of the list can be either a string or an agent, and the only thing the position in the list affects is what orde

Re: tuple.index()

Nick Maclaren wrote: > > Which is tantamount to saying that Python doesn't support mutable > heterogeneous sequences, even though they are not locked out. That > is more than just odd - it is almost unbelievable. They are a very > basic data structure, after all! What a fuss about something so i

Re: tuple.index()

In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> writes: |> |> > Nope. Sorry. Consider the old model where an I/O list is an ordered |> > sequence of strings and agents (effectively procedure calls), with no |> > constraints on how those are ordered. With your specification, that |> >

Re: tuple.index()

Nick Maclaren wrote: > Nope. Sorry. Consider the old model where an I/O list is an ordered > sequence of strings and agents (effectively procedure calls), with no > constraints on how those are ordered. With your specification, that > is neither heterogenous nor homogenous :-) I don't see any

Re: tuple.index()

In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> writes: |> |> > It does explain why you think of lists as homogeneous, but the |> > analogy doesn't hold water on closer inspection. There doesn't seem |> > to be ANYTHING in the specification or implementation that assumes |> > lists

Re: tuple.index()

Nick Maclaren wrote: > It does explain why you think of lists as homogeneous, but the > analogy doesn't hold water on closer inspection. There doesn't seem > to be ANYTHING in the specification or implementation that assumes > lists are homogeneous. Then what do you think is suggested by the

Re: tuple.index()

Nick Maclaren wrote: > In article <[EMAIL PROTECTED]>, > "J. Clifford Dyer" <[EMAIL PROTECTED]> writes: > |> > |> On the contrary, I think that example fits perfectly with my definition > |> of homogenous. If there is no constraint on position, then what is the > |> position determinative of? Or

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "J. Clifford Dyer" <[EMAIL PROTECTED]> writes: |> |> On the contrary, I think that example fits perfectly with my definition |> of homogenous. If there is no constraint on position, then what is the |> position determinative of? Order in the queue. Nothing more.

Re: tuple.index()

Nick Maclaren wrote: > In article <[EMAIL PROTECTED]>, > "J. Clifford Dyer" <[EMAIL PROTECTED]> writes: > |> > |> How about: "A heterogenous sequence is one in which each element plays a > |> unique role, specific to its position in the sequence. A homogenous > |> sequence is one in which positio

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "J. Clifford Dyer" <[EMAIL PROTECTED]> writes: |> |> How about: "A heterogenous sequence is one in which each element plays a |> unique role, specific to its position in the sequence. A homogenous |> sequence is one in which position is determinative of nothing |>

Re: tuple.index()

James Stroud wrote: > Christoph Zwerschke wrote: >> "Inhomogenous" in some meaning of the word --> tuple > > I think that you have nailed it here. I don't think anyone on this list > is capable of giving a "concrete" (as you have put it) operational > definition of "inhomogenous". They will resort

Re: tuple.index()

Roy Smith wrote: > In article <[EMAIL PROTECTED]>, > greg <[EMAIL PROTECTED]> wrote: > >> Roy Smith wrote: >> >>> The struct does lookup by name, the tuple is inherently index based. >> I was trying to help people understand the distinction >> we're talking about by showing an example of the same

Re: tuple.index()

On 19 Dec 2006 10:01:47 GMT, Nick Maclaren <[EMAIL PROTECTED]> wrote: > > It does explain why you think of lists as homogeneous, but the > analogy doesn't hold water on closer inspection. There doesn't seem > to be ANYTHING in the specification or implementation that assumes > lists are homoge

Re: tuple.index()

In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> writes: |> Nick Maclaren wrote: |> |> > Unfortunately, you are confusing the issue, because there are far |> > more extraneous aspects than relevant ones, and your view of the |> > similarities requires looking at the issue in a very strang

Re: tuple.index()

Nick Maclaren wrote: > Unfortunately, you are confusing the issue, because there are far > more extraneous aspects than relevant ones, and your view of the > similarities requires looking at the issue in a very strange way. > I think that I can see what you mean, but only just. Each member of a s

Re: tuple.index()

In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> writes: |> Roy Smith wrote: |> |> > The struct does lookup by name, the tuple is inherently index based. |> |> I was trying to help people understand the distinction |> we're talking about by showing an example of the same |> distinction i

Re: tuple.index()

In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> wrote: > Roy Smith wrote: > > > The struct does lookup by name, the tuple is inherently index based. > > I was trying to help people understand the distinction > we're talking about by showing an example of the same > distinction in anoth

Re: tuple.index()

Roy Smith wrote: > The struct does lookup by name, the tuple is inherently index based. I was trying to help people understand the distinction we're talking about by showing an example of the same distinction in another language where it's much clearer. There are a great many ways in which C str

Re: tuple.index()

In article <[EMAIL PROTECTED]>, greg <[EMAIL PROTECTED]> writes: |> |> > A collection is inhomogeneous if, for some attribute that is needed |> > for at least one action on at least one element of the collection, |> > the attribute is not shared by all elements of the collection. |>

Re: tuple.index()

greg <[EMAIL PROTECTED]> wrote: > A Python tuple is like a C struct, and a Python list is like a C array. A Python list is more like C++/STL vector than an array, but that's probably picking nits. The real problem is that while the *intent* of the Python tuple is to act like a C/C++ struct (aga

Re: tuple.index()

Nick Maclaren wrote: > A collection is inhomogeneous if, for some attribute that is needed > for at least one action on at least one element of the collection, > the attribute is not shared by all elements of the collection. If you mean "attribute" in the Python sense, then this is wr

Re: tuple.index()

In article <[EMAIL PROTECTED]>, James Stroud <[EMAIL PROTECTED]> writes: |> Christoph Zwerschke wrote: |> |> > "Inhomogenous" in some meaning of the word --> tuple |> |> I think that you have nailed it here. I don't think anyone on this list |> is capable of giving a "concrete" (as you have put

Re: tuple.index()

Christoph Zwerschke wrote: > "Inhomogenous" in some meaning of the word --> tuple I think that you have nailed it here. I don't think anyone on this list is capable of giving a "concrete" (as you have put it) operational definition of "inhomogenous". They will resort to use cases and thus cloud

Re: tuple.index()

In article <[EMAIL PROTECTED]>, Christoph Zwerschke <[EMAIL PROTECTED]> writes: |> |> I just found that there is indeed some mentioning in the FAQ here: |> http://www.python.org/doc/faq/general/#why-are-there-separate-tuple-and-list-data-types |> But it is a bit vague, too, and does not mention

Re: tuple.index()

James Stroud wrote: > Christoph Zwerschke wrote: >> Maybe there would be less dispute if this dogma/convention(?) "Tuples >> are for heterogeneous data, list are for homogeneous data" would be >> written down somewhere in the tutorial, reference or in PEP8, so >> people would be aware of it. >

Re: tuple.index()

Hendrik van Rooyen wrote: > From a practical point of view, the only reason to use a tuple instead > of a list for anything seems to be that you want to use it as a key in a > dict... > > Otherwise, why bother with these recalcitrant things that you can't > change or index, or append to or anythi

Re: tuple.index()

"Christoph Zwerschke" <[EMAIL PROTECTED]> wrote: > I don't think it's a problem of false logic but the problem that > "homogenous data" is not defined. > > We probably agree that it usually makes perfect sense to use tuples for > coordinates. But in certain mathematical algorithms it also makes s

Re: tuple.index()

Christoph Zwerschke wrote: > Maybe there would be less dispute if this dogma/convention(?) "Tuples > are for heterogeneous data, list are for homogeneous data" would be > written down somewhere in the tutorial, reference or in PEP8, so people > would be aware of it. This is a good idea. It has

Re: tuple.index()

Simon Brunning wrote: > So, you can infer no semantic meaning from an items position in the list. [...] > The fact that an item is the nth item is a tuple *means* something. Wouldn't it be nice, then, to find out where something is in a tuple so that one could infer semantic meaning from its po

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Tim Golden" <[EMAIL PROTECTED]> writes: |> [Christoph Zwerschke] |> |> > And can somebody explain what is exactly meant with |> > "homogenous data"? |> |> This seems to have been explained a few times |> recently :) Basically, if you have a "list of xs" |> and re

Re: tuple.index()

Christoph Zwerschke wrote: > The statement "if you are looking for index() or count() for your > tuples, you're using the wrong container type" is too extreme I think. I > would agree with "it *may indicate* that you should better use lists". And also if that statement was correct, I would argue

Re: tuple.index()

On 12/15/06, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > > If you have a tuple containing, say, a 2d coordinate pair, > > and remove something from it, it's no longer a coordinate pair. > > Now here comes the ambiguity. If you interpret "x" as "coordinate tuple" > it would be still one (a 1-t

Re: tuple.index()

On 12/15/06, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > Maybe there would be less dispute if this dogma/convention(?) "Tuples > are for heterogeneous data, list are for homogeneous data" would be > written down somewhere in the tutorial, reference or in PEP8, so people > would be aware of it.

Re: tuple.index()

Tim Golden wrote: > Christoph Zwerschke wrote: >> And can somebody explain what is exactly meant with >> "homogenous data"? > > This seems to have been explained a few times > recently :) Basically, if you have a "list of xs" > and remove one item from it, it is still a "list of xs", According to

Re: tuple.index()

On 14 Dec 2006 06:24:38 -0800, Glenn Hutchings <[EMAIL PROTECTED]> wrote: > What I'm saying is that from the > perspective of someone not interested in design issues, it seems like > an omission for tuples to be missing the non-modifying methods that > lists have. >From the perpective of somone no

Re: tuple.index()

[Christoph Zwerschke] > And can somebody explain what is exactly meant with > "homogenous data"? This seems to have been explained a few times recently :) Basically, if you have a "list of xs" and remove one item from it, it is still a "list of xs", where "xs" might be people, coordinate-pairs, n

Re: tuple.index()

Maybe there would be less dispute if this dogma/convention(?) "Tuples are for heterogeneous data, list are for homogeneous data" would be written down somewhere in the tutorial, reference or in PEP8, so people would be aware of it. And can somebody explain what is exactly meant with "homogenous

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Carl Banks" <[EMAIL PROTECTED]> writes: |> |> > It isn't a misplaced fear, but the extra protection |> > provided by doing that only for tuples is like locking one door out of |> > ten to deter burglars - good practice, if there is no downside, but not |> > worth

Re: tuple.index()

Nick Maclaren wrote: > It isn't a misplaced fear, but the extra protection > provided by doing that only for tuples is like locking one door out of > ten to deter burglars - good practice, if there is no downside, but not > worth putting much effort into. Maybe "inconsistent" fear is a better wor

Re: tuple.index()

Nick Maclaren wrote: > Indeed. The code to sort out the problem was trivial. I was curious > as to the reason, since there was no technical or mathematical one you still haven't explained what your solution to the technical issues is, though. if simply repeating that something is trivial would

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Carl Banks" <[EMAIL PROTECTED]> writes: |> Glenn Hutchings wrote: |> > Simon Brunning wrote: |> > > It's because, philosophically, a Python tuple isn't just a read-only list. |> > |> > But there are situations where you might want to treat it as a |> > read-only l

Re: tuple.index()

Glenn Hutchings wrote: > Simon Brunning wrote: > > It's because, philosophically, a Python tuple isn't just a read-only list. > > But there are situations where you might want to treat it as a > read-only list. E.g., an argument to a function, so that you can > guarantee the function won't modify

Re: tuple.index()

Fredrik Lundh wrote: > so which Guido should you trust more? not to mention the "If you have a need for using count() or index() on tuples, you're using them the wrong way" guy: http://mail.python.org/pipermail/patches/2001-February/004071.html -- http://mail.python.org/mailman/listinf

Re: tuple.index()

Nick Maclaren wrote: > Guido's response is fine - we didn't because we didn't think that it > was worth doing. One can dissent, but it makes perfect sense. so which Guido should you trust more? the "tuples should not be used for arrays of homogeneous data" and "searching tuples doesn't make s

Re: tuple.index()

In article <[EMAIL PROTECTED]>, Carsten Haese <[EMAIL PROTECTED]> writes: |> > |> |> > |> so where would you put such an "index" implementation so it would work on |> > |> ANY data structure that can be subscripted by an integer value ? |> > |> > In the same place you put the subscription metho

Re: tuple.index()

Nick Maclaren wrote: > See my response to Georg Brandl (specifically the memo. to myself). "reductio ad absurdum" and "arbitrary handwaving" are two different things, though. -- http://mail.python.org/mailman/listinfo/python-list

Re: tuple.index()

Nick Maclaren wrote: > In the same place you put the subscription method, clearly. which is? -- http://mail.python.org/mailman/listinfo/python-list

Re: tuple.index()

On 2006-12-14, Nick Maclaren <[EMAIL PROTECTED]> wrote: > > In article <[EMAIL PROTECTED]>, > "Glenn Hutchings" <[EMAIL PROTECTED]> writes: >|> >|> > I remain baffled. I accept the explanations, but what I am now >|> > confused by is the reason for the explanations >|> >|> Maybe this archive

Re: tuple.index()

On Thu, 2006-12-14 at 15:57 +, Nick Maclaren wrote: > In article <[EMAIL PROTECTED]>, > "Fredrik Lundh" <[EMAIL PROTECTED]> writes: > |> > |> > The point is that an index method makes sense on ANY data structure that > |> > can be subscripted by an integer value but, for reasons that aren't at

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> writes: |> |> > The point is that an index method makes sense on ANY data structure that |> > can be subscripted by an integer value but, for reasons that aren't at |> > all clear, is not defined for Python tuples. There is no t

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Glenn Hutchings" <[EMAIL PROTECTED]> writes: |> |> > I remain baffled. I accept the explanations, but what I am now |> > confused by is the reason for the explanations |> |> Maybe this archive posting, straight from the horse's mouth, will clear |> things up

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> writes: |> Nick Maclaren wrote: |> |> > If lists are intended to be homogeneous, then they should be checked |> > for that, and an exception raised when an attempt is to make them |> > non-homogeneous. |> |> so how would that ch

Re: tuple.index()

Nick Maclaren wrote: > The point is that an index method makes sense on ANY data structure that > can be subscripted by an integer value but, for reasons that aren't at > all clear, is not defined for Python tuples. There is no technical or > mathematical reason why it shouldn't be. so where wou

Re: tuple.index()

Nick Maclaren wrote: > I remain baffled. I accept the explanations, but what I am now > confused by is the reason for the explanations Maybe this archive posting, straight from the horse's mouth, will clear things up once and for all... http://www.python.org/search/hypermail/python-1992/028

Re: tuple.index()

In article <[EMAIL PROTECTED]>, Georg Brandl <[EMAIL PROTECTED]> writes: |> > |> > If lists are intended to be homogeneous, then they should be checked |> > for that, and an exception raised when an attempt is to make them |> > non-homogeneous. At least as a Python checking option. |> |> There

Re: tuple.index()

Nick Maclaren schrieb: > In article <[EMAIL PROTECTED]>, > "Glenn Hutchings" <[EMAIL PROTECTED]> writes: > |> Fredrik Lundh wrote: > |> > |> > if you don't want to understand the design, nobody can force you. but > arguing > |> > that the people behind the design "don't get it" isn't very practi

Re: tuple.index()

Nick Maclaren wrote: > If lists are intended to be homogeneous, then they should be checked > for that, and an exception raised when an attempt is to make them > non-homogeneous. so how would that check work, given that Python's type model is based on duck typing http://en.wikipedia.org/wiki

Re: tuple.index()

In article <[EMAIL PROTECTED]>, "Glenn Hutchings" <[EMAIL PROTECTED]> writes: |> Fredrik Lundh wrote: |> |> > if you don't want to understand the design, nobody can force you. but arguing |> > that the people behind the design "don't get it" isn't very practical. |> |> I'm not arguing that at

Re: tuple.index()

Fredrik Lundh wrote: > if you don't want to understand the design, nobody can force you. but arguing > that the people behind the design "don't get it" isn't very practical. I'm not arguing that at all. What I'm saying is that from the perspective of someone not interested in design issues, it s

Re: tuple.index()

On 14 Dec 2006 06:05:12 -0800, Glenn Hutchings <[EMAIL PROTECTED]> wrote: > It's not my own code I'm worried about. :-) If you want a language that protects you not only from your own mistakes, but also the mistakes of others, well, err, sorry, I'm not sure I can help you. Eiffel, perhaps?

Re: tuple.index()

Glenn Hutchings wrote: > Python is first and foremost a practical language; what lists and > tuples are supposedly "for" strikes me as being irrelevant. if you don't want to understand the design, nobody can force you. but arguing that the people behind the design "don't get it" isn't very pract

Re: tuple.index()

On 12/14/06, Simon Brunning <[EMAIL PROTECTED]> wrote: > Tell that to Guido. They are his arguments. On 2nd thoughts, don't. He has enough on his plate at the moment. ;-) -- Cheers, Simon B [EMAIL PROTECTED] http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/py

Re: tuple.index()

On 14 Dec 2006 06:03:07 -0800, Glenn Hutchings <[EMAIL PROTECTED]> wrote: > All the previous arguments > about "homogenous" and "heterogenous" in this thread sound bogus to me. > Python is first and foremost a practical language; what lists and > tuples are supposedly "for" strikes me as being irre

Re: tuple.index()

Fredrik Lundh wrote: > if you cannot trust your own code not to modify objects you pass to it, > I'm not sure Python's the right language for you. It's not my own code I'm worried about. :-) -- http://mail.python.org/mailman/listinfo/python-list

Re: tuple.index()

Roberto Bonvallet wrote: > list(my_arg).index(...) Absolutely -- you can work around the limitation without any problems. But the question is, why doesn't the list type share all its non-modifying methods with the tuple type? All the previous arguments about "homogenous" and "heterogenous" in thi

Re: tuple.index()

Glenn Hutchings wrote: > But there are situations where you might want to treat it as a > read-only list. E.g., an argument to a function, so that you can > guarantee the function won't modify it. if you cannot trust your own code not to modify objects you pass to it, I'm not sure Python's the r

Re: tuple.index()

Glenn Hutchings wrote: > But there are situations where you might want to treat it as a > read-only list. E.g., an argument to a function, so that you can > guarantee the function won't modify it. In that case, it makes sense > for the non-modifying methods (index() and count()) to be available.

Re: tuple.index()

Simon Brunning wrote: > It's because, philosophically, a Python tuple isn't just a read-only list. But there are situations where you might want to treat it as a read-only list. E.g., an argument to a function, so that you can guarantee the function won't modify it. In that case, it makes sense

Re: tuple.index()

On 14 Dec 2006 11:24:04 GMT, Nick Maclaren <[EMAIL PROTECTED]> wrote: > > Why doesn't the tuple type have an index method? It seems such a > bizarre restriction that there must be some reason for it. Yes, > I know it's a fairly rare requirement. It's because, philosophically, a Python tuple isn'

Re: tuple.index()

Nick Maclaren wrote: > My understanding of the difference between a tuple and a list is > PRECISELY that the former is immutable and the latter mutable. while tuples can be used as "frozen lists", that's definitely not what they are, from a design perspective. just like in math [1], a Python tu

Re: tuple.index()

On 12/14/06, Nick Maclaren <[EMAIL PROTECTED]> wrote: > Well, if that were so, it would explain things. But lists AREN'T > necessarily homogeneous! > > >>> a=[52,"abc",[1,2],5.6] > >>> print repr(a) > [52, 'abc', [1, 2], 5.5996] It's not a technical restriction, as I said, but it's wh

Re: tuple.index()

Nick Maclaren wrote: > Why doesn't the tuple type have an index method? It seems such a > bizarre restriction that there must be some reason for it. In fact, tuples have no non-__underscored__ methods at all. The list count() method would also be useful for tuples, since it doesn't modify anythi

Re: tuple.index()

In article <[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]> writes: |> |> > Why doesn't the tuple type have an index method? It seems such a |> > bizarre restriction that there must be some reason for it. |> |> hah! not being able to remove or add things to tuples is an even |> bizarrer

Re: tuple.index()

Nick Maclaren wrote: > Why doesn't the tuple type have an index method? It seems such a > bizarre restriction that there must be some reason for it. hah! not being able to remove or add things to tuples is an even bizarrer restriction! -- http://mail.python.org/mailman/listinfo/python-list

tuple.index()

Why doesn't the tuple type have an index method? It seems such a bizarre restriction that there must be some reason for it. Yes, I know it's a fairly rare requirement. Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list

Re: tuple.index(item)

[David Isaac] > > Why don't tuples support an index method? > > It seems natural enough ... [Peter Hansen] > This question has been posed several (many?) times in the past. See the > archives for more detail, but basically the answer that is usually given > is this: > > Tuples are intended to be

Re: tuple.index(item)

David Isaac wrote: > Why don't tuples support an index method? > It seems natural enough ... This question has been posed several (many?) times in the past. See the archives for more detail, but basically the answer that is usually given is this: Tuples are intended to be used somewhat like C

Re: tuple.index(item)

Jules Dubois wrote: > On Monday 11 July 2005 15:23, David Isaac <[EMAIL PROTECTED]> > (<[EMAIL PROTECTED]>) wrote: > >>Why don't tuples support an index method? > > 19:27:32:~ $ python > Python 2.3.5 (#2, Jun 19 2005, 13:28:00) > [GCC 3.3.6 (Debian 1:3.3.6-6)] on linux2 > Type "help", "co

Re: tuple.index(item)

On Monday 11 July 2005 15:23, David Isaac <[EMAIL PROTECTED]> (<[EMAIL PROTECTED]>) wrote: > Why don't tuples support an index method? 19:27:32:~ $ python Python 2.3.5 (#2, Jun 19 2005, 13:28:00) [GCC 3.3.6 (Debian 1:3.3.6-6)] on linux2 Type "help", "copyright", "credits" or "license" for

tuple.index(item)

Why don't tuples support an index method? It seems natural enough ... Thanks, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list