Robert Kern wrote:
Steve Holden wrote:
The effbot wrote:
George Sakkis wrote:
It would be useful if list.sort() accepted two more optional
parameters
useful for what? what's the use case ?
John Machin then wrote, without quoting any context at all:
Use case?
He means under what
Steve Holden wrote:
Robert Kern wrote:
I believe that John was asking George for a use case rather than asking
Fredrik
what a use case was.
In which case, as I pointed out, John would have done better to quote a
little more context.
No argument here.
--
Robert Kern
I have come to
Context? The whole message asked for a new feature. Please tell me what
context I should have supplied.
--
http://mail.python.org/mailman/listinfo/python-list
Feature?
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Love me, love my blog http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
--
http://mail.python.org/mailman/listinfo/python-list
Getting a patch ready for checkin (corrected, documented, reviewed, and
tested) is only part of the battle. The real challenge of language
design is figuring out whether something should be done.
Adding optional parameters to a method makes its invocation slower and
makes the API harder to learn
Am Sonntag 21 Mai 2006 18:55 schrieb Raymond Hettinger:
If the perf gain is small and the use cases are infrequent, the
addition is likely unwarranted. There is an entire class of feature
requests that are more appropriate as recipes than for inclusion in the
language.
The thing is: having
John Machin wrote:
Context? The whole message asked for a new feature. Please tell me what
context I should have supplied.
When you reply to a message, please quote part of that message. That's what was
meant by context.
--
Robert Kern
I have come to believe that the whole world is an
John Machin wrote:
Use case?
quicksort! :)
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
--
http://mail.python.org/mailman/listinfo/python-list
The effbot wrote:
George Sakkis wrote:
It would be useful if list.sort() accepted two more optional
parameters
useful for what? what's the use case ?
John Machin then wrote, without quoting any context at all:
Use case?
He means under what circumstances do you see someone actually
Steve Holden wrote:
The effbot wrote:
George Sakkis wrote:
It would be useful if list.sort() accepted two more optional
parameters
useful for what? what's the use case ?
John Machin then wrote, without quoting any context at all:
Use case?
He means under what circumstances do you see
Fredrik Lundh wrote:
George Sakkis wrote:
It would be useful if list.sort() accepted two more optional
parameters
+1
useful for what? what's the use case ?
Actually, I was in need of such a construct only few weeks ago. The
task was to organize playlists
of an mp3 player. I wanted to
Am Donnerstag 18 Mai 2006 19:27 schrieb George Sakkis:
It would be useful if list.sort() accepted two more optional
parameters, start and stop, so that you can sort a slice in place.
I've just submitted:
http://sourceforge.net/tracker/index.php?func=detailaid=1491804group_id=5470atid=305470
Heiko Wundram wrote:
Am Donnerstag 18 Mai 2006 19:27 schrieb George Sakkis:
It would be useful if list.sort() accepted two more optional
parameters, start and stop, so that you can sort a slice in place.
I've just submitted:
Am Freitag 19 Mai 2006 23:24 schrieb George Sakkis:
This is great, thanks Heiko ! Any idea on the chances of being
considered for inclusion in 2.5 ?
Don't ask me, I'm not one of the core developers... ;-) But, anyway, the
people on python-dev are doing their best to review patches. Just: I
It would be useful if list.sort() accepted two more optional
parameters, start and stop, so that you can sort a slice in place. In
other words,
x = range(100)
x.sort(start=3, stop=-1)
would be equivalent to
x[3:-1] = sorted(x[3:-1])
but more efficient and without repeating the slice twice.
George Sakkis wrote:
It would be useful if list.sort() accepted two more optional
parameters
useful for what? what's the use case ?
/F
--
http://mail.python.org/mailman/listinfo/python-list
Use case?
--
http://mail.python.org/mailman/listinfo/python-list
George Sakkis wrote:
It would be useful if list.sort() accepted two more optional
parameters, start and stop, so that you can sort a slice in place. In
other words,
x = range(100)
x.sort(start=3, stop=-1)
would be equivalent to
x[3:-1] = sorted(x[3:-1])
but more efficient and
Fredrik Lundh wrote:
George Sakkis wrote:
It would be useful if list.sort() accepted two more optional
parameters
useful for what? what's the use case ?
/F
Although there is a use case (see below), I don't think it's strictly
necessary in this case. Arguments to add it:
- Don't Repeat
Am Donnerstag 18 Mai 2006 22:13 schrieb Raymond Hettinger:
This is a false optimization. The slicing steps are O(n) and the sort
step is O(n log n) unless the data has some internal structure that
Timsort can use to get closer to O(n).
If you implemented this and timed in it real apps, I
20 matches
Mail list logo
