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 methods
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 predict that
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
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 ``count``.
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 formed from
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 Month, etc., and it
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 tuple when
On Apr 14, 11:59 am, Paul Rubin http://[EMAIL PROTECTED] 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 being any
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).
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 the
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 the
On Apr 15, 1:55 am, Paul Rubin http://[EMAIL PROTECTED] 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 indexing (O(log
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 of costly search
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
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, a bad
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 we can't
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
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_ be,
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 sort the
On Apr 13, 11:05 pm, Paul Rubin http://[EMAIL PROTECTED] 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
canonical string
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
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 are always defending
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 inconsistent
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 easier if
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 simply add
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 choose the option
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 python
has chosen to
Antoon Pardon said unto the world upon 04/13/2007 02:46 AM:
On 2007-04-12, Steven D'Aprano [EMAIL PROTECTED] wrote:
snip
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
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:
snip
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
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 worked
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 given
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 to me.
--
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 being
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 aliases for it any
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]
to succeed, but
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
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 dictionary keys.
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, 4] in [1, 2, 3, 4, 5,
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, 4] in [1, 2, 3, 4, 5,
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 perversely allow extension to
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:
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:
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?
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 suggests
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, does
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?
Name
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, does it
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
method,
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 be
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
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
--
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 sequences of homogeneous
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 =
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 the
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. the
-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 other option: you care that 32 is somewhere
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* difference
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.:
T = (Fred,
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 designed to be more like
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-list@python.org
Subject: Re: tuples, index method, Python's
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 desire for tuple.index
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')
I think you
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
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 know where to
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
one
-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 a) a third party module that you cannot
On 2007-04-06, Carsten Haese [EMAIL PROTECTED] wrote:
On Fri, 2007-04-06 at 11:33 -0700, 7stud wrote:
On Apr 6, 7:56 am, Paul Boddie [EMAIL PROTECTED] wrote:
The problem with 7stud's quote from GvR is that it's out of date:
I would argue that it shows the very guy who invented the language
On 2007-04-08, Carsten Haese [EMAIL PROTECTED] wrote:
On Sun, 2007-04-08 at 07:51 -0700, Paul Rubin wrote:
Carsten Haese [EMAIL PROTECTED] writes:
Maybe we can add such methods to the PyPy tuples for some time, to
experimentally see if they make the language worse :-)
Adding useless
On 2007-04-09, Georg Brandl [EMAIL PROTECTED] wrote:
Paul Rubin schrieb:
Carsten Haese [EMAIL PROTECTED] writes:
Will tuples also get a sort method? What about append and extend? pop?
__iadd__? __delslice__?
They are immutable so they won't get .sort() etc. sorted(...) already
works on
Antoon Pardon [EMAIL PROTECTED] wrote:
When a new feature is requested, the burden of proof is on the requester
to show that it has uses.
I don't agree. Good or bad design is not dependant on what is
implemented and what is not.
There is a cost to every new language feature: it has to be
On 2007-04-10, Duncan Booth [EMAIL PROTECTED] wrote:
Antoon Pardon [EMAIL PROTECTED] wrote:
When a new feature is requested, the burden of proof is on the requester
to show that it has uses.
I don't agree. Good or bad design is not dependant on what is
implemented and what is not.
There
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 adding to
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 usable
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 shown up.
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
because
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.
No
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
except
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, and I'll
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
users. Good 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 doesn't
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 can't think
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
involves, in part,
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 this:
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
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 precisely the
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 ternary
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 natural
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, maintained, and above
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 that by
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 disagree, but in my
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:
opponents = tuple(x for x in p
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 commit it.
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 severe
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 particular
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 our
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 is my revised
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 tuple. Please
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 raise ValueError if
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 have a list,
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
1 - 100 of 127 matches
Mail list logo
