[issue403693] tupleobject.c: implement tuple.index() and tuple.count()

Change by admin : -- github: None -> 33887 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33560] tuple.index() could return a more explicit error message

Serhiy Storchaka added the comment: This is a duplicate of issue13349. -- nosy: +serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed superseder: -> Non-informative error message in index() and remove() functions

[issue33560] tuple.index() could return a more explicit error message

Change by Roundup Robot : -- keywords: +patch pull_requests: +6612 stage: -> patch review ___ Python tracker ___

[issue33560] tuple.index() could return a more explicit error message

New submission from Cyril Roelandt <croel...@redhat.com>: The tuple.index() method returns an error message that does not allow users to know what element was being looked for inside the tuple: >>> ().index(1) Traceback (most recent call last): File "", line 1, in

[issue30477] tuple.index error message improvement

Changes by Brett Cannon : -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker ___

[issue30477] tuple.index error message improvement

Martin Panter added the comment: Also discussed in Issue 13349 -- nosy: +martin.panter superseder: -> Non-informative error message in index() and remove() functions ___ Python tracker

[issue30477] tuple.index error message improvement

schen added the comment: What is the rationale for the inconsistency between tuples and lists here? ().index(0) ValueError: tuple.index(x): x not in tuple [].index(0) ValueError: 0 is not in list In this simple artificial case, it seems clear to me that the list version (which is similar

[issue30477] tuple.index error message improvement

Raymond Hettinger added the comment: > Is it a performance worry? It really depends on what people are doing with their down. If indexing potentially missing values is common, there will be a performance impact. Also, the cost of a __repr__ varies wildly depending on the data (i.e. a

[issue30477] tuple.index error message improvement

Joe Jevnik added the comment: As a more meta question: I have noticed that many error messages in the stdlib use PyErr_SetString, or choose to use the type name instead of the repr of the object. Is there a reason for this? I normally try to fill the error message with as much context as

[issue30477] tuple.index error message improvement

Joe Jevnik added the comment: I agree, "%R in tuple" is enough information for me. This would also remove the need to manually repr the object. -- type: enhancement -> ___ Python tracker

[issue30477] tuple.index error message improvement

Brett Cannon added the comment: I'm wondering if including the whole "tuple.index(%R)" part is still necessary? The traceback will tell you what method you called, so wouldn't "%R not in tuple" be enough? -- components: +Interpreter Core t

[issue30477] tuple.index error message improvement

New submission from Joe Jevnik: The old error of tuple.index(x): x not in tuple seemed very confusing to me. It was also harder to quickly understand what the program was doing wrong. This saves people a second pass through the program under the debugger because they can just see what

[issue5495] ValueError exception of tuple.index(x) gives imprecise error message

New submission from Retro vinet...@gmail.com: t = (0, 1, 2, 3, 4, 5, 6, 7) t.index(8) Traceback (most recent call last): File stdin, line 1, in module ValueError: tuple.index(x): x not in list The error message x not in list should have been x not in tuple. Please fix the error message

[issue5495] ValueError exception of tuple.index(x) gives imprecise error message

STINNER Victor victor.stin...@haypocalc.com added the comment: Attached patch fixes the error message. -- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file13339/not_in_tuple.patch ___ Python tracker rep...@bugs.python.org

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() 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

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()

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, and the

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 for an example of

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 consider a modern

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()

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 are

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: | | 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

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

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 order

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 about how

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 strange way. | I

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 homogeneous.

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 distinction in

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 to use cases

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()

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 position is

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. By my |

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? Order in the

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 in another

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

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

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. | | If you

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

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 another language

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 anything

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. This is a

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 whether

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 the

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 it)

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 wrong,

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()

[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, numbers or

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 not

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 that

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. It's

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-tuple), but

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 that

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 remove one item from

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

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 taken

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 sense to

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()

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! /F --

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. 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

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 what lists are

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 tuple

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't

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()

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()

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

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 this

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()

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 irrelevant.

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/ --

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 practical.

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()

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

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 all. What I'm

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

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 practical. | | I'm not

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 you have the

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...

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 would

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 check work, given

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 once and for

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 technical or

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 | all clear,

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 posting, straight

Re: tuple.index()

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

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. /F -- http://mail.python.org/mailman/listinfo/python-list

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 sense

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 /F --

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 it.

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 list. E.g., an

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()

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 word.

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 putting much

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

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 more

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, copyright, credits

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)

[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 used

  1   2   >