On Wed, 4 Nov 2009 10:10:30 am Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano st...@pearwood.info
wrote:
Since I was the person who decided that arbitrary meant give a
different result each time, I should answer that.
You're obviously talking about a *random*
On Wed, 4 Nov 2009 11:54:47 am Greg Ewing wrote:
Steven D'Aprano wrote:
I don't know how expensive it is to create a set iterator,
Not expensive enough to justify burdening the set type with
extra functionality that will be extremely rarely used.
As my previous posts on this topic tried to
On Wed, Nov 4, 2009 at 6:34 AM, Steven D'Aprano st...@pearwood.info wrote:
On Wed, 4 Nov 2009 11:54:47 am Greg Ewing wrote:
Steven D'Aprano wrote:
I don't know how expensive it is to create a set iterator,
Not expensive enough to justify burdening the set type with
extra functionality that
On Tue, Nov 3, 2009 at 12:19 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element feels
horrible. Is there anyone here who _likes_ it?
State might
Antoine Pitrou wrote:
Guido van Rossum guido at python.org writes:
Picking a random element can be done in O(1) only if the data
structure supports access by index, which Python's hash tables don't.
Well, at the implementation level, they can. You'd just have to pick a new
random index until
Steven D'Aprano wrote:
I don't know how expensive it is to create a set iterator,
Not expensive enough to justify burdening the set type with
extra functionality that will be extremely rarely used.
--
Greg
___
Python-Dev mailing list
On Tue, Nov 3, 2009 at 4:46 PM, Steven D'Aprano st...@pearwood.info wrote:
def pick_two_cards(hand):
assert isinstance(hand, (set, frozenset))
assert len(hand) == 5
return (hand.pick(), hand.pick())
Even if pick() chose random, you still might end up picking the same card
twice.
On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 3 Nov 2009 09:19:38 am Greg Ewing wrote:
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element
feels horrible. Is
Guido van Rossum guido at python.org writes:
You're obviously talking about a *random* element. This is a separate
use case (though I agree many people don't know the difference).
Picking a random element can be done in O(1) only if the data
structure supports access by index, which
On Tue, Nov 3, 2009 at 5:10 PM, Antoine Pitrou solip...@pitrou.net wrote:
Greg Ewing greg.ewing at canterbury.ac.nz writes:
Picking a random element can be done in O(1) only if the data
structure supports access by index, which Python's hash tables don't.
Well, at the implementation
Greg Ewing greg.ewing at canterbury.ac.nz writes:
Picking a random element can be done in O(1) only if the data
structure supports access by index, which Python's hash tables don't.
Well, at the implementation level, they can. You'd just have to pick a new
random index until it points
On Tue, Nov 3, 2009 at 12:20 AM, Yuvgoog Greenle ubershme...@gmail.com wrote:
On Tue, Nov 3, 2009 at 12:19 AM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the
On Tue, 3 Nov 2009 09:19:38 am Greg Ewing wrote:
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element
feels horrible. Is there anyone here who _likes_ it?
It doesn't sound very useful to me.
On 04Nov2009 09:46, Steven D'Aprano st...@pearwood.info wrote:
| On Tue, 3 Nov 2009 09:19:38 am Greg Ewing wrote:
| Cameron Simpson wrote:
| Personally, I'm for the iteration spec in a lot of ways.
For the record, I've since, in mere hours or day, been convinced my
preference was misguided.
I
Cameron Simpson cs at zip.com.au writes:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element feels
horrible. Is there anyone here who _likes_ it?
I do. Since the caller is asking for an arbitrary element, returning the
Hi,
all your points are valid -- for the experienced Python programmer who has
stumbled across this issue already and solved it in one of several ways. All
your points, however, do not support the one obvious way to do it philosophy
of Python. It's all about making Python even more clean and
Antoine Pitrou wrote:
Cameron Simpson cs at zip.com.au writes:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element feels
horrible. Is there anyone here who _likes_ it?
I do. Since the caller is asking for an arbitrary
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element feels
horrible. Is there anyone here who _likes_ it?
It doesn't sound very useful to me. However, an iterating
version of it doesn't sound any more
On 02Nov2009 10:21, Antoine Pitrou solip...@pitrou.net wrote:
| Cameron Simpson cs at zip.com.au writes:
|
| Personally, I'm for the iteration spec in a lot of ways.
|
| Firstly, a .get()/.pick() that always returns the same element feels
| horrible. Is there anyone here who _likes_ it?
|
On 30Oct2009 20:43, Chris Bergstresser ch...@subtlety.com wrote:
| On Fri, Oct 30, 2009 at 8:29 PM, Steven D'Aprano st...@pearwood.info wrote:
| Iterating over an iterable is
| what iterators are for.
|
| set.get(), or set.pick() as Wikipedia calls it, isn't for iterating over
| sets. It is
Am Freitag, 30. Oktober 2009 03:58:16 schrieb Steven D'Aprano:
To clarify point 3, given:
x = set.get()
y = set.get()
then x and y will only be the same element if set has length one.
However, given:
x = set.get()
set.add(el)
set.remove(el)
y = set.get()
there are no guarantees
Steven D'Aprano schrieb:
On Wed, 28 Oct 2009 04:47:59 am Raymond Hettinger wrote:
A dict.get() can be meaningfully used in a loop (because the key can
vary). A set.get() returns the same value over and over again
(because there is no key).
I don't believe anyone has requested those
On Fri, Oct 30, 2009 at 09:37:36PM +0100, Georg Brandl wrote:
I don't like this. It gives a set object a hidden state, something that
AFAICS no other builtin has. Iterating over an iterable is what iterators
are for.
It also makes the object thread-unsafe; there's no way for two threads
to
On Sat, 31 Oct 2009 07:27:22 am A.M. Kuchling wrote:
On Fri, Oct 30, 2009 at 09:37:36PM +0100, Georg Brandl wrote:
I don't like this. It gives a set object a hidden state, something
that AFAICS no other builtin has.
All objects have a reference count field which is hidden from Python
code.
2009/10/30 Steven D'Aprano st...@pearwood.info:
On Sat, 31 Oct 2009 07:27:22 am A.M. Kuchling wrote:
On Fri, Oct 30, 2009 at 09:37:36PM +0100, Georg Brandl wrote:
I don't like this. It gives a set object a hidden state, something
that AFAICS no other builtin has.
All objects have a
On Fri, Oct 30, 2009 at 8:29 PM, Steven D'Aprano st...@pearwood.info wrote:
Iterating over an iterable is
what iterators are for.
set.get(), or set.pick() as Wikipedia calls it, isn't for iterating over
sets. It is for getting an arbitrary element from the set.
If the requirement that
On Wed, 28 Oct 2009 04:47:59 am Raymond Hettinger wrote:
A dict.get() can be meaningfully used in a loop (because the key can
vary). A set.get() returns the same value over and over again
(because there is no key).
I don't believe anyone has requested those semantics. The suggested
semantics
Guido van Rossum wrote:
My gut tells me it is bad API design to collapse these two use cases.
Probably because the implementations won't have much in common: (1)
should just pick the first valid element, while (2) should use the
normal hash lookup algorithm (shared with 'in', .add() etc.).
As
[Chris Bergstresser]
Still, I think my
point stands--it's a clear extrapolation from the existing dict.get().
Not really. One looks-up a key and supplies a default value if not found.
The other, set.get(), doesn't have a key to lookup.
A dict.get() can be meaningfully used in a loop
Raymond Hettinger python at rcn.com writes:
[Chris Bergstresser]
Still, I think my
point stands--it's a clear extrapolation from the existing dict.get().
Not really. One looks-up a key and supplies a default value if not found.
The other, set.get(), doesn't have a key to lookup.
On Tue, Oct 27, 2009 at 1:59 PM, Antoine Pitrou solip...@pitrou.net wrote:
Raymond Hettinger python at rcn.com writes:
[Chris Bergstresser]
Still, I think my
point stands--it's a clear extrapolation from the existing dict.get().
Not really. One looks-up a key and supplies a default
On Tue, Oct 27, 2009 at 02:20:04PM -0400, geremy condra wrote:
On Tue, Oct 27, 2009 at 1:59 PM, Antoine Pitrou solip...@pitrou.net wrote:
Raymond Hettinger python at rcn.com writes:
set.getone() then ?
ugh- other spellings much preferred.
set[] ? (Just kidding, really.)
Oleg.
--
Raymond Hettinger wrote:
A dict.get() can be meaningfully used in a loop (because the key can vary).
A set.get() returns the same value over and over again (because there is
no key).
There are two ideas of set.get floating about:
1) get an arbitrary object
2) get the object in the set with
On Tue, Oct 27, 2009 at 12:47 PM, Raymond Hettinger pyt...@rcn.com wrote:
[Chris Bergstresser]
Still, I think my
point stands--it's a clear extrapolation from the existing dict.get().
Not really. One looks-up a key and supplies a default value if not found.
The other, set.get(), doesn't
On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more
and more and more and more and more and more and more:
This topic needs its own flippin' newsgroup.
S
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Oct 27, 2009 at 3:06 PM, sstein...@gmail.com
sstein...@gmail.com wrote:
On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more and
more and more and more and more and more and more:
This topic needs its own flippin' newsgroup.
S
Don't like it? Mute the conversation
On Tue, Oct 27, 2009 at 11:50 AM, Terry Reedy tjre...@udel.edu wrote:
There are two ideas of set.get floating about:
1) get an arbitrary object
2) get the object in the set with the same 'value'(hash+eq) as an input arg
(the intern case). In this case, there is a 'key', even if it is somewhat
On Tue, Oct 27, 2009 at 3:13 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Oct 27, 2009 at 11:50 AM, Terry Reedy tjre...@udel.edu wrote:
There are two ideas of set.get floating about:
1) get an arbitrary object
2) get the object in the set with the same 'value'(hash+eq) as an input arg
sstein...@gmail.com wrote:
On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more
and more and more and more and more and more and more:
Actually, I wrote 7 succinct lines that summarized and made a proposal.
In general, I snip when quoting and write concisely as possible.
On Oct 27, 2009, at 11:02 PM, Terry Reedy wrote:
sstein...@gmail.com wrote:
This topic needs its own flippin' newsgroup.
You could have said just that, appropriate or not, without dumping
on anyone in particular.
I was not trying to dump on you in particular, I picked a random
message
Chris Bergstresser]
I like the proposed set.get() method, personally.
Sets have been implemented in many languages, but I've only
seen one that implemented this functionality (the arb function
in SETL). For the most part, it seems that this is an uncommon need.
Also consider that
On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger pyt...@rcn.com wrote:
P.S. It is weird that this thread is gaining traction at the same
time as the moratorium thread. Go figure :-)
I'm beginning to think maybe adding a method to a built-in object type
*should* fall under the moratorium.
On Mon, Oct 26, 2009 at 3:56 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger pyt...@rcn.com wrote:
P.S. It is weird that this thread is gaining traction at the same
time as the moratorium thread. Go figure :-)
I'm beginning to think maybe
On Mon, Oct 26, 2009 at 3:56 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger pyt...@rcn.com wrote:
P.S. It is weird that this thread is gaining traction at the same
time as the moratorium thread. Go figure :-)
I'm beginning to think maybe
Jesse Noller jnoller at gmail.com writes:
So far, fiddling with the PEP, I'm on the fence - adding a method to a
built-in object type is sort of a grey area (at least in my mind). It
depends on if doing so significantly alters the language/syntax.
We have recently added things like
On Mon, Oct 26, 2009 at 7:56 PM, Guido van Rossum gu...@python.org wrote:
I'm beginning to think maybe adding a method to a built-in object type
*should* fall under the moratorium.
Another possible test case for this decision is the int.from_bytes and
int.to_bytes methods, proposed a while ago,
On Mon, Oct 26, 2009 at 1:19 PM, Antoine Pitrou solip...@pitrou.net wrote:
Jesse Noller jnoller at gmail.com writes:
So far, fiddling with the PEP, I'm on the fence - adding a method to a
built-in object type is sort of a grey area (at least in my mind). It
depends on if doing so
For those of you who want to tinker with it, I posted the patch against the
current trunk at http://bugs.python.org/issue7212
Have fun,
wr
Am Montag, 26. Oktober 2009 21:32:32 schrieb Guido van Rossum:
On Mon, Oct 26, 2009 at 1:19 PM, Antoine Pitrou solip...@pitrou.net wrote:
Jesse Noller
48 matches
Mail list logo
