Re: tuples, index method, Python's design

In article <[EMAIL PROTECTED]>, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 2 Mar, 19:06, Alan Isaac <[EMAIL PROTECTED]> wrote: > > On April 12th, 2007 at 10:05 PM Alan Isaac wrote: > > > > > The avoidance of tuples, so carefully defended in other > > > terms, is often rooted (I claim) in habits

Re: tuples, index method, Python's design

Paul Boddie schrieb: > On 2 Mar, 19:06, Alan Isaac <[EMAIL PROTECTED]> wrote: >> On April 12th, 2007 at 10:05 PM Alan Isaac wrote: >> >>> The avoidance of tuples, so carefully defended in other >>> terms, is often rooted (I claim) in habits formed from >>> need for list methods like ``index`` and `

Re: tuples, index method, Python's design

Paul Boddie wrote: > Here's the tracker item that may have made it happen: > http://bugs.python.org/issue1696444 > I think you need to thank Raymond Hettinger for championing the > cause. ;-) Yes indeed! Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list

Re: tuples, index method, Python's design

On 2 Mar, 19:06, Alan Isaac <[EMAIL PROTECTED]> wrote: > On April 12th, 2007 at 10:05 PM Alan Isaac wrote: > > > The avoidance of tuples, so carefully defended in other > > terms, is often rooted (I claim) in habits formed from > > need for list methods like ``index`` and ``count``. > > Indeed, I p

Re: tuples, index method, Python's design

On April 12th, 2007 at 10:05 PM Alan Isaac wrote: > The avoidance of tuples, so carefully defended in other > terms, is often rooted (I claim) in habits formed from > need for list methods like ``index`` and ``count``. > Indeed, I predict that Python tuples will eventually have > these met

Re: tuples, index method, Python's design

On 4/12/07, Alan Isaac <[EMAIL PROTECTED]> wrote: > Chris Mellon said: > > Sure. I have never done this. In fact, I have only ever written code > > that converted a tuple to a list once, and it was because I wanted > > pop(), not index() > > Well then you apparently made a *mistake*: you chose a tu

Re: tuples, index method, Python's design

In article <[EMAIL PROTECTED]>, "Hendrik van Rooyen" <[EMAIL PROTECTED]> wrote: > "Donn Cave" <[EMAIL PROTECTED]> wrote: > > > > > Well, yes - consider for example the "tm" tuple returned > > from time.localtime() - it's all integers, but heterogeneous > > as could be - tm[0] is Year, tm[1] is

Re: tuples, index method, Python's design

Roel Schroeven <[EMAIL PROTECTED]> writes: > In this case s[0] is not the full Unicode scalar, but instead just the > first part of the surrogate pair consisting of 0x1D40 (in s[0]) and > 0x (in s[1]). Agggh. After much head scratching I think I now understand what you are saying. This a

Re: tuples, index method, Python's design

On Apr 15, 8:56 am, Roel Schroeven <[EMAIL PROTECTED]> wrote: > Paul Rubin schreef: > > > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > >> Indexing cost, memory efficiency, and canonical representation: pick > >> two. You can't use a canonical representation (scalar values) without > >> some sort

Re: tuples, index method, Python's design

On Apr 15, 1:55 am, Paul Rubin wrote: > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > Indexing cost, memory efficiency, and canonical representation: pick > > two. You can't use a canonical representation (scalar values) without > > some sort of costly search when inde

Re: tuples, index method, Python's design

Paul Rubin schreef: > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: >> Indexing cost, memory efficiency, and canonical representation: pick >> two. You can't use a canonical representation (scalar values) without >> some sort of costly search when indexing (O(log n) probably) or by >> expanding to t

Re: tuples, index method, Python's design

Paul Rubin: > I still don't get it. UTF-16 is just a data compression scheme, right? > I mean, s[17] isn't the 17th character of the (unicode) string regardless > of which memory byte it happens to live at? It could be that that accessing > it takes more than constant time, but that's hidden by

Re: tuples, index method, Python's design

"Rhamphoryncus" <[EMAIL PROTECTED]> writes: > Indexing cost, memory efficiency, and canonical representation: pick > two. You can't use a canonical representation (scalar values) without > some sort of costly search when indexing (O(log n) probably) or by > expanding to the worst-case size (UTF-32

Re: tuples, index method, Python's design

On Apr 14, 11:59 am, Paul Rubin wrote: > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > Nope, it's pretty fundamental to working with text, unicode only being > > an extreme example: there's a wide number of ways to break down a > > chunk of text, making the odds of "e"

Re: tuples, index method, Python's design

On 2007-04-13, Steve Holden <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> On 2007-04-13, Steve Holden <[EMAIL PROTECTED]> wrote: >>> Antoon Pardon wrote: On 2007-04-12, Carsten Haese <[EMAIL PROTECTED]> wrote: > On Thu, 2007-04-12 at 14:10 +, Antoon Pardon wrote: >> People a

Re: tuples, index method, Python's design

"Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > > > i = s.index(e) => s[i] = e > > > > Then this algorithm is no longer guaranteed to work with strings. > > > It never worked correctly on unicode strings anyway (which becomes the > > > canonical string in python 3.0). > > > > What?! Are you sur

Re: tuples, index method, Python's design

On Apr 13, 11:05 pm, Paul Rubin wrote: > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > > i = s.index(e) => s[i] = e > > > Then this algorithm is no longer guaranteed to work with strings. > > It never worked correctly on unicode strings anyway (which becomes the > > c

Re: tuples, index method, Python's design

"Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > So to increase consistency, the .index method should be removed > from lists, as well, IMO. If you find yourself doing a linear > search, something is wrong. > I agree. You should at the very least make it a binary search. To do that you have to so

Re: tuples, index method, Python's design

On Sat, 14 Apr 2007 08:19:36 +0200, Hendrik van Rooyen wrote: > This is the point where the whole thing falls apart in my head and > I get real confused - I can't find a reason why, list or tuple, the first > item can't be something, the second something else, etc... It's not that they _can't_ b

Re: tuples, index method, Python's design

> The use case has already been discussed. Removing the pointless > inconsistency between lists and tuples means you can stop having to > remember it, so you can free up brain cells for implementing useful > things. That increases your programming productivity. So to increase consistency, the .i

Re: tuples, index method, Python's design

"Donn Cave" <[EMAIL PROTECTED]> wrote: > > Well, yes - consider for example the "tm" tuple returned > from time.localtime() - it's all integers, but heterogeneous > as could be - tm[0] is Year, tm[1] is Month, etc., and it > turns out that not one of them is alike. The point is exactly > that w

Re: tuples, index method, Python's design

"Carsten Haese" <[EMAIL PROTECTED]> wrote: 8< > sense in its context. Nobody seems to be complaining about "+" behaving > "inconsistently" depending on whether you're adding numbers or > sequences. I would If I thought it would do some good - the plus sign as a joiner was, I think,

Re: tuples, index method, Python's design

"Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > i = s.index(e) => s[i] = e > > Then this algorithm is no longer guaranteed to work with strings. > It never worked correctly on unicode strings anyway (which becomes the > canonical string in python 3.0). What?! Are you sure? That sounds broken

Re: tuples, index method, Python's design

Steve Holden <[EMAIL PROTECTED]> writes: > This is just a bald restatement of the same argument you feel makes it > desirable to add an index() method to tuples. If taken to its logical > (and ridiculous) extreme there should only be one sequence type in > Python. That doesn't sound ridiculous giv

Re: tuples, index method, Python's design

On Apr 13, 1:32 am, Antoon Pardon <[EMAIL PROTECTED]> wrote: > Suppose someone writes a function that acts on a sequence. > The algorithm used depending on the following invariant. > > i = s.index(e) => s[i] = e > > Then this algorithm is no longer guaranteed to work with strings. It never worke

Re: tuples, index method, Python's design

Brian van den Broek wrote: > Antoon Pardon said unto the world upon 04/13/2007 02:46 AM: >> On 2007-04-12, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > > > >>> So much fuss over such a little thing... yes it would be nice if tuples >>> grew an index method, but it isn't hard to work around the l

Re: tuples, index method, Python's design

Antoon Pardon said unto the world upon 04/13/2007 02:46 AM: > On 2007-04-12, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >> So much fuss over such a little thing... yes it would be nice if tuples >> grew an index method, but it isn't hard to work around the lack. > > Yes it is a little thing. Bu

Re: tuples, index method, Python's design

Antoon Pardon wrote: > On 2007-04-13, Steve Holden <[EMAIL PROTECTED]> wrote: >> Antoon Pardon wrote: >>> On 2007-04-12, Carsten Haese <[EMAIL PROTECTED]> wrote: On Thu, 2007-04-12 at 14:10 +, Antoon Pardon wrote: > People are always defending duck-typing in this news group and now pyt

Re: tuples, index method, Python's design

On 2007-04-13, Steve Holden <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> On 2007-04-12, Carsten Haese <[EMAIL PROTECTED]> wrote: >>> On Thu, 2007-04-12 at 14:10 +, Antoon Pardon wrote: People are always defending duck-typing in this news group and now python has chosen to choo

Re: tuples, index method, Python's design

Antoon Pardon wrote: > On 2007-04-12, Carsten Haese <[EMAIL PROTECTED]> wrote: >> On Thu, 2007-04-12 at 14:10 +, Antoon Pardon wrote: >>> People are always defending duck-typing in this news group and now python >>> has chosen to choose the option that makes duck-typing more difficult. >> Au co

Re: tuples, index method, Python's design

On Fri, 13 Apr 2007 07:46:58 +, Antoon Pardon wrote: >> So much fuss over such a little thing... yes it would be nice if tuples >> grew an index method, but it isn't hard to work around the lack. > > Yes it is a little thing. But if it is such a little thing why do > the developers don't simp

Re: tuples, index method, Python's design

On 2007-04-12, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Thu, 12 Apr 2007 07:37:38 +, Antoon Pardon wrote: > >> I once had a problem I like to solve by having a dictionary >> where the keys were multidimensional points on an integer grid. >> For a number of reasons I thought it would be e

Re: tuples, index method, Python's design

On 2007-04-12, Carsten Haese <[EMAIL PROTECTED]> wrote: > On Thu, 2007-04-12 at 14:10 +, Antoon Pardon wrote: >> People are always defending duck-typing in this news group and now python >> has chosen to choose the option that makes duck-typing more difficult. > > Au contraire! The "inconsisten

Re: tuples, index method, Python's design

In article <[EMAIL PROTECTED]>, Antoon Pardon <[EMAIL PROTECTED]> wrote: > On 2007-04-11, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > > In <[EMAIL PROTECTED]>, Antoon Pardon wrote: > > > >> On 2007-04-11, Steven D'Aprano <[EMAIL PROTECTED]> > >> wrote: > >>> Lists are designed for sequ

Re: tuples, index method, Python's design

"Terry Reedy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > The main point of immutability is hashability by value (rather than by id). You are treating an effect as a cause. This is the main point *because* of an artifical constraint on tuples. Cheers, Alan Isaac -- http://mai

Re: tuples, index method, Python's design

Chris Mellon said: > Sure. I have never done this. In fact, I have only ever written code > that converted a tuple to a list once, and it was because I wanted > pop(), not index() Well then you apparently made a *mistake*: you chose a tuple when you wanted a mutable object. That is really beside

Re: tuples, index method, Python's design

On Thu, 12 Apr 2007 07:37:38 +, Antoon Pardon wrote: > I once had a problem I like to solve by having a dictionary > where the keys were multidimensional points on an integer grid. > For a number of reasons I thought it would be easier if I could > use lists, but most people argued that would

Re: tuples, index method, Python's design

In article <[EMAIL PROTECTED]>, "Alan Isaac" <[EMAIL PROTECTED]> wrote: > As I said: > I doubt that *anyone* who programs in Python > has not encountered the situation where they change > a tuple to a list *solely* for the purpose of getting > access to the index method. This suggests a missing >

Re: tuples, index method, Python's design

Alan Isaac wrote: > I am still puzzled by this discussion. > > As I said: > I doubt that *anyone* who programs in Python > has not encountered the situation where they change > a tuple to a list *solely* for the purpose of getting > access to the index method. This suggests a missing > method, doe

Re: tuples, index method, Python's design

"Alan Isaac" <[EMAIL PROTECTED]> wrote: > I doubt that *anyone* who programs in Python > has not encountered the situation where they change > a tuple to a list *solely* for the purpose of getting > access to the index method. This suggests a missing > method, does it not? Who has not done this?

Re: tuples, index method, Python's design

"Alan Isaac" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I doubt that *anyone* who programs in Python | has not encountered the situation where they change | a tuple to a list *solely* for the purpose of getting | access to the index method. This suggests a missing | method, doe

Re: tuples, index method, Python's design

On 4/12/07, Alan Isaac <[EMAIL PROTECTED]> wrote: > I am still puzzled by this discussion. > > As I said: > I doubt that *anyone* who programs in Python > has not encountered the situation where they change > a tuple to a list *solely* for the purpose of getting > access to the index method. This s

Re: tuples, index method, Python's design

I am still puzzled by this discussion. As I said: I doubt that *anyone* who programs in Python has not encountered the situation where they change a tuple to a list *solely* for the purpose of getting access to the index method. This suggests a missing method, does it not? Who has not done this?

Re: tuples, index method, Python's design

Carsten Haese: > Nobody seems to be complaining about "+" behaving > "inconsistently" depending on whether you're adding numbers or > sequences. We can learn a bit from the D language too, it uses ~ for array/string concatenation, look for the "Array Concatenation" here: http://www.digitalmars.com

Re: tuples, index method, Python's design

On Thu, 2007-04-12 at 14:10 +, Antoon Pardon wrote: > People are always defending duck-typing in this news group and now python > has chosen to choose the option that makes duck-typing more difficult. Au contraire! The "inconsistent" behavior of "in" is precisely what duck-typing is all about:

Re: tuples, index method, Python's design

On 2007-04-12, Steve Holden <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> On 2007-04-11, Terry Reedy <[EMAIL PROTECTED]> wrote: >>> "BJrn Lindqvist" <[EMAIL PROTECTED]> wrote in message >>> news:[EMAIL PROTECTED] >>> On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: One might pervers

Re: tuples, index method, Python's design

Antoon Pardon wrote: > On 2007-04-11, Terry Reedy <[EMAIL PROTECTED]> wrote: >> "BJrn Lindqvist" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: >>> One might perversely allow extension to lists and tuples to allow >>> >>>[3

Re: tuples, index method, Python's design

Antoon Pardon wrote: > On 2007-04-11, Terry Reedy <[EMAIL PROTECTED]> wrote: >> "BJrn Lindqvist" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: >>> One might perversely allow extension to lists and tuples to allow >>> >>>[3

Re: tuples, index method, Python's design

On 2007-04-12, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 12 Apr, 09:37, Antoon Pardon <[EMAIL PROTECTED]> wrote: >> >> Why then does python itself provide immutables? I find this reasoning >> more than baffling. There has been all these arguments about why >> it is best to use immutables as dicti

Re: tuples, index method, Python's design

On 12 Apr, 09:37, Antoon Pardon <[EMAIL PROTECTED]> wrote: > > Why then does python itself provide immutables? I find this reasoning > more than baffling. There has been all these arguments about why > it is best to use immutables as dictionary keys. You've answered your own question. If you had a

Re: tuples, index method, Python's design

On 2007-04-11, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "BJrn Lindqvist" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: >> One might perversely allow extension to lists and tuples to allow >> >>[3, 4] in [1, 2, 3, 4, 5, 6]

Re: tuples, index method, Python's design

On 2007-04-11, Chris Mellon <[EMAIL PROTECTED]> wrote: > On 11 Apr 2007 08:37:39 -0700, Paul Boddie <[EMAIL PROTECTED]> wrote: >> On 11 Apr, 16:14, "Chris Mellon" <[EMAIL PROTECTED]> wrote: >> > >> > If you want a language that just adds whatever methods anyone thinks >> > of, along with whatever a

Re: tuples, index method, Python's design

On 2007-04-11, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > > So how about it? All you people who desperately want tuples to grow an > index method -- will any of you donate your time to write and maintain the > code? But as far as I understood the code is already there; the code for list.index be

RE: tuples, index method, Python's design

> -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of Chris Mellon > Sent: Wednesday, April 11, 2007 9:12 AM > To: python-list@python.org > Subject: Re: tuples, index method, Python's design > > > So, when you have

Re: tuples, index method, Python's design

On Wed, 11 Apr 2007 10:57:19 -0500, Chris Mellon <[EMAIL PROTECTED]> wrote: > > The primary use case for index on tuple is because people use them as > immutable lists. That's fine as far as it goes, but I want to know > what the justification is for using an immutable list, and if you have >

Re: tuples, index method, Python's design

On 11 Apr 2007 08:37:39 -0700, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 11 Apr, 16:14, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > > > If you want a language that just adds whatever methods anyone thinks > > of, along with whatever aliases for it any can think of, to every data > > type, you k

Re: tuples, index method, Python's design

On 11 Apr, 16:14, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > If you want a language that just adds whatever methods anyone thinks > of, along with whatever aliases for it any can think of, to every data > type, you know where to find Ruby. Nobody is asking for Ruby, as far as I can see. I even

Re: tuples, index method, Python's design

On Wed, 11 Apr 2007 13:13:20 +, Antoon Pardon wrote: >> Lists are designed for sequences of homogeneous items, e.g.: >> >> L = [1, 2, 4, 8, 16, 32] >> while tuples are designed to be more like structs or records, with >> heterogeneous items, e.g.: >> >> T = ("Fred", 32, 12.789, {}, None, '\t')

Re: tuples, index method, Python's design

On 4/10/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > > while not game_has_ended: > > > for current_player in p: > > > player_does_something(current_player) > > > > > > > I'm curious why someone would even consider using a tuple in this case > > regardless. I think that much of the desir

Re: tuples, index method, Python's design

On 4/11/07, Hamilton, William <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:python- > > [EMAIL PROTECTED] On Behalf Of Steven > D'Aprano > > Sent: Wednesday, April 11, 2007 7:49 AM > > To: python

Re: tuples, index method, Python's design

On 2007-04-11, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > In <[EMAIL PROTECTED]>, Antoon Pardon wrote: > >> On 2007-04-11, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >>> Lists are designed for sequences of homogeneous items, e.g.: >>> >>> L = [1, 2, 4, 8, 16, 32] >>> while tuples are des

Re: tuples, index method, Python's design

In <[EMAIL PROTECTED]>, Antoon Pardon wrote: > On 2007-04-11, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >> Lists are designed for sequences of homogeneous items, e.g.: >> >> L = [1, 2, 4, 8, 16, 32] >> while tuples are designed to be more like structs or records, with >> heterogeneous items, e.g.

Re: tuples, index method, Python's design

On 2007-04-11, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Wed, 11 Apr 2007 08:57:43 +0200, Hendrik van Rooyen wrote: > >> I can write: >> >> L = [a,b,c,d,e,f] >> T= (a,b,c,d,e,f) >> >> The difference between the two things is that I can add to >> and change L, but not T. > > No, that's *one

RE: tuples, index method, Python's design

> -Original Message- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of Steven D'Aprano > Sent: Wednesday, April 11, 2007 7:49 AM > To: python-list@python.org > Subject: Re: tuples, index method, Python's design > > (There is one

Re: tuples, index method, Python's design

On Wed, 11 Apr 2007 08:57:43 +0200, Hendrik van Rooyen wrote: > I can write: > > L = [a,b,c,d,e,f] > T= (a,b,c,d,e,f) > > The difference between the two things is that I can add to > and change L, but not T. No, that's *one* difference between the two things. There are other differences, e.g.

Re: tuples, index method, Python's design

On 10 Apr, 20:04, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > This is a rare enough use case and is easy enough to work around (convert it > to > a list, write a helper function) that I don't think it's worth any > language change overhead at all. It isn't a language change: it's a change to th

Re: tuples, index method, Python's design

"Carsten Haese" <[EMAIL PROTECTED]> wrote: > I'm just a user with no influence on the development of Python itself, > but in my humble opinion, the non-existence of tuple.index is more > pythonic than its existence would be. I really cannot follow the logic behind this statement. I can write: L

Re: tuples, index method, Python's design

On Tue, 2007-04-10 at 21:23 -0700, Paul Rubin wrote: > Carsten Haese <[EMAIL PROTECTED]> writes: > > You have a point. Here is my revised solution: > > > > assert current_player in p > > opponents = tuple(x for x in p if x is not current_player) > > Still wrong on two counts. First, assert is a

Re: tuples, index method, Python's design

Carsten Haese <[EMAIL PROTECTED]> writes: > You have a point. Here is my revised solution: > > assert current_player in p > opponents = tuple(x for x in p if x is not current_player) Still wrong on two counts. First, assert is a no-op if optimization is turned on. Second, your version returns a

Re: tuples, index method, Python's design

"Paul Boddie" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | always enlightening/entertaining to see the rationales given for the | rejection of this and other features, in contrast to things like "y if | x else z" which just seem to mysteriously acquire momentum and then | power t

Re: tuples, index method, Python's design

"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: > One might perversely allow extension to lists and tuples to allow > >[3, 4] in [1, 2, 3, 4, 5, 6] > > to succeed, but that's forcing the use case beyond normal l

RE: tuples, index method, Python's design

Carsten Haese wrote: > assert current_player in p > opponents = tuple(x for x in p if x is not current_player) That would perform better as: opponents = tuple(x for x in p if x is not current_player) assert opponents Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list

Re: tuples, index method, Python's design

> > while not game_has_ended: > > for current_player in p: > > player_does_something(current_player) > > > > I'm curious why someone would even consider using a tuple in this case > regardless. I think that much of the desire for tuple.index is because > people use a tuple where they could ha

Re: tuples, index method, Python's design

On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > On Tue, 2007-04-10 at 19:21 +0200, BJörn Lindqvist wrote: > > On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > > > > > opponents = tuple(x for x in p if x is not current_player) > > > > > > > > > Your alternative is wrong because it wont

Re: tuples, index method, Python's design

On Tue, 2007-04-10 at 19:21 +0200, BJörn Lindqvist wrote: > On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > > > > opponents = tuple(x for x in p if x is not current_player) > > > > > > > Your alternative is wrong because it wont raise ValueError if > > > current_player is not present in the

Re: tuples, index method, Python's design

On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > > > opponents = tuple(x for x in p if x is not current_player) > > > > > Your alternative is wrong because it wont raise ValueError if > > current_player is not present in the tuple. Please revise your > > "solution." > > You have a point. Here

Re: tuples, index method, Python's design

BJörn Lindqvist: > > One might perversely allow extension to lists and tuples to allow > >[3, 4] in [1, 2, 3, 4, 5, 6] > > to succeed, but that's forcing the use case beyond normal limits. The > > point I am trying to make is that circumstances alter cases, and that we > > can't always rely on

Re: tuples, index method, Python's design

On 2007-04-10, Carsten Haese <[EMAIL PROTECTED]> wrote: > On Tue, 2007-04-10 at 13:21 +, Antoon Pardon wrote: >> > But if you are so eager to rewrite, how about the following: >> > >> > I am using the struct module to get binary data from a file. >> > Sometimes I want to skip until I find a p

Re: tuples, index method, Python's design

On 10 Apr, 17:44, Carsten Haese <[EMAIL PROTECTED]> wrote: > > You have a point. Here is my revised solution: > > assert current_player in p > opponents = tuple(x for x in p if x is not current_player) > > The added advantage is that AssertionError is better than IndexError for > conveying that a s

Re: tuples, index method, Python's design

On 10 Apr, 17:29, Steve Holden <[EMAIL PROTECTED]> wrote: > > You can call something non-controversial when it generates a thread like > this? :-) It's really a storm in a teacup. The acid test would be to > generate a patch that added the method and then see if you could get a > committer to commi

Re: tuples, index method, Python's design

On Tue, 2007-04-10 at 11:44 -0400, Carsten Haese wrote: > On Tue, 2007-04-10 at 17:10 +0200, BJörn Lindqvist wrote: > > On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > > > i = p.index(current_player) > > > opponents = p[:i-1] + p[i+1:] > > > > > > An alternative is this: > > > > > > opponent

Re: tuples, index method, Python's design

On Tue, 2007-04-10 at 17:10 +0200, BJörn Lindqvist wrote: > On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > > i = p.index(current_player) > > opponents = p[:i-1] + p[i+1:] > > > > An alternative is this: > > > > opponents = tuple(x for x in p if x is not current_player) > > > > You may disag

Re: tuples, index method, Python's design

Paul Boddie wrote: > On 10 Apr, 15:57, Steve Holden <[EMAIL PROTECTED]> wrote: >> The point I am trying to make is that circumstances alter cases, and that we >> can't always rely on our intuition to determine how specific methods >> work, let alone whether they are available. > > But it's telling

Re: tuples, index method, Python's design

On 4/10/07, Steve Holden <[EMAIL PROTECTED]> wrote: > Paul Boddie wrote: > > On 10 Apr, 11:48, Antoon Pardon <[EMAIL PROTECTED]> wrote: > >> On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: > >> > >>> There is a cost to every new language feature: it has to be implemented, > >>> documented, m

Re: tuples, index method, Python's design

On 4/10/07, Carsten Haese <[EMAIL PROTECTED]> wrote: > i = p.index(current_player) > opponents = p[:i-1] + p[i+1:] > > An alternative is this: > > opponents = tuple(x for x in p if x is not current_player) > > You may disagree, but in my opinion, the alternative is better because > it is a more nat

Re: tuples, index method, Python's design

Carsten Haese wrote: > On Tue, 2007-04-10 at 09:57 -0400, Steve Holden wrote: >> I hear the screams of "just add the index() method to tuples and have >> done with it" and, to an extent, can sympathize with them. But that way >> lies creeping featurism and the next thing you know we'll have a ter

Re: tuples, index method, Python's design

On 10 Apr, 15:57, Steve Holden <[EMAIL PROTECTED]> wrote: > > The point I am trying to make is that circumstances alter cases, and that we > can't always rely on our intuition to determine how specific methods > work, let alone whether they are available. But it's telling that by adopting precisel

Re: tuples, index method, Python's design

On Tue, 2007-04-10 at 09:57 -0400, Steve Holden wrote: > I hear the screams of "just add the index() method to tuples and have > done with it" and, to an extent, can sympathize with them. But that way > lies creeping featurism and the next thing you know we'll have a ternary > operator in the la

Re: tuples, index method, Python's design

On Tue, 2007-04-10 at 13:21 +, Antoon Pardon wrote: > > But if you are so eager to rewrite, how about the following: > > > > I am using the struct module to get binary data from a file. > > Sometimes I want to skip until I find a particular binary > > number. Somewhat simplified it looks like

Re: tuples, index method, Python's design

Paul Boddie wrote: > On 10 Apr, 11:48, Antoon Pardon <[EMAIL PROTECTED]> wrote: >> On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: >> >>> There is a cost to every new language feature: it has to be implemented, >>> documented, maintained, and above all learned by the users. Good design >>> i

Re: tuples, index method, Python's design

On 2007-04-10, Carsten Haese <[EMAIL PROTECTED]> wrote: > On 10 Apr 2007 09:48:41 GMT, Antoon Pardon wrote >> If someone states: "Show me your use case for using tuple.index and I >> will show you how to avoid it." or words to that effect I think there >> is little use trying. > > Or maybe you just

Re: tuples, index method, Python's design

On 2007-04-10, Carsten Haese <[EMAIL PROTECTED]> wrote: > >> Adding the index method to tuples is not adding a feature. It is >> removing a limitation. > > The non-existence of tuple.index is only a limitation if there is a need > for the method to exist. Please prove that this need exists. It doe

Re: tuples, index method, Python's design

On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: > Antoon Pardon <[EMAIL PROTECTED]> wrote: > >> On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: >>> There is a cost to every new language feature: it has to be >>> implemented, documented, maintained, and above all learned by the >>> use

Re: tuples, index method, Python's design

On Tue, 2007-04-10 at 12:29 +, Antoon Pardon wrote: > On 2007-04-10, Carsten Haese <[EMAIL PROTECTED]> wrote: > > On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote > >> On 2007-04-06, Carsten Haese <[EMAIL PROTECTED]> wrote: > >> > If you have a use case for tuple.index, please show it to me, an

Re: tuples, index method, Python's design

Antoon Pardon <[EMAIL PROTECTED]> wrote: > On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: >> There is a cost to every new language feature: it has to be >> implemented, documented, maintained, and above all learned by the >> users. Good design involves, in part, not adding to these burdens

Re: tuples, index method, Python's design

On 2007-04-10, Carsten Haese <[EMAIL PROTECTED]> wrote: > On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote >> On 2007-04-06, Carsten Haese <[EMAIL PROTECTED]> wrote: >> > If you have a use case for tuple.index, please show it to me, and I'll >> > show you what you should be using instead of a tuple

Re: tuples, index method, Python's design

On 10 Apr 2007 09:48:41 GMT, Antoon Pardon wrote > If someone states: "Show me your use case for using tuple.index and I > will show you how to avoid it." or words to that effect I think there > is little use trying. Or maybe you just can't think of any good use cases, and that's annoying you beca

Re: tuples, index method, Python's design

On 10 Apr 2007 07:31:13 GMT, Antoon Pardon wrote > On 2007-04-06, Carsten Haese <[EMAIL PROTECTED]> wrote: > > If you have a use case for tuple.index, please show it to me, and I'll > > show you what you should be using instead of a tuple. > > No wonder no convincing use cases for tuples have show

Re: tuples, index method, Python's design

On 2007-04-10, Paul Boddie <[EMAIL PROTECTED]> wrote: >> Now with implementation and maintaining. If you would start with a class >> of sequence which classes like tuple and list would inherit from, then >> there also would be a single function to be implemented and maintained. >> It would just be

Re: tuples, index method, Python's design

On 10 Apr, 11:48, Antoon Pardon <[EMAIL PROTECTED]> wrote: > On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> wrote: > > > There is a cost to every new language feature: it has to be implemented, > > documented, maintained, and above all learned by the users. Good design > > involves, in part, not a

  1   2   >