On Wed, Nov 4, 2009 at 6:34 AM, Steven D'Aprano 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 will be
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 trie
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
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* element. This i
On 04Nov2009 09:46, Steven D'Aprano 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 _do_ still feel
Guido van Rossum 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 Python's
On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano 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 there a
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
On Tue, Nov 3, 2009 at 4:46 PM, Steven D'Aprano 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. Is that really w
Greg Ewing 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 5:10 PM, Antoine Pitrou wrote:
> Greg Ewing 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. Yo
On Tue, Nov 3, 2009 at 12:20 AM, Yuvgoog Greenle wrote:
> On Tue, Nov 3, 2009 at 12:19 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
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
Python-Dev@pyth
Antoine Pitrou wrote:
Guido van Rossum 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 it poin
On Tue, Nov 3, 2009 at 12:19 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?
>>
>
>
State might cause people to
On 02Nov2009 10:21, Antoine Pitrou wrote:
| Cameron Simpson 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 c
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 us
Antoine Pitrou wrote:
> Cameron Simpson 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 arbitrar
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
Cameron Simpson 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 sam
On 30Oct2009 20:43, Chris Bergstresser wrote:
| On Fri, Oct 30, 2009 at 8:29 PM, Steven D'Aprano 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 ele
On Fri, Oct 30, 2009 at 8:29 PM, Steven D'Aprano 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 get/pick() c
2009/10/30 Steven D'Aprano :
> 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
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
c
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
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 tho
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 n
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
semanti
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.).
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
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.
Th
On Tue, Oct 27, 2009 at 3:13 PM, Guido van Rossum wrote:
> On Tue, Oct 27, 2009 at 11:50 AM, Terry Reedy 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 t
On Tue, Oct 27, 2009 at 11:50 AM, Terry Reedy 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
> abstract ra
On Tue, Oct 27, 2009 at 3:06 PM, 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 (thank you gma
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
http://mail.python.org/ma
On Tue, Oct 27, 2009 at 12:47 PM, Raymond Hettinger 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 have a
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 th
On Tue, Oct 27, 2009 at 02:20:04PM -0400, geremy condra wrote:
> On Tue, Oct 27, 2009 at 1:59 PM, Antoine Pitrou wrote:
> > Raymond Hettinger rcn.com> writes:
> > set.getone() then ?
>
> ugh- other spellings much preferred.
set[] ? (Just kidding, really.)
Oleg.
--
Oleg Broytman
On Tue, Oct 27, 2009 at 1:59 PM, Antoine Pitrou wrote:
> Raymond Hettinger 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
Raymond Hettinger 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.
set.g
[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 (becaus
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 wrote:
> > Jesse Noller gmail.com> writes:
On Mon, Oct 26, 2009 at 1:19 PM, Antoine Pitrou wrote:
> Jesse Noller 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 languag
On Mon, Oct 26, 2009 at 7:56 PM, Guido van Rossum 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, and implemente
Jesse Noller 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 float.fromhex()
On Mon, Oct 26, 2009 at 3:56 PM, Guido van Rossum wrote:
> On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger 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-
On Mon, Oct 26, 2009 at 3:56 PM, Guido van Rossum wrote:
> On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger 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-
On Mon, Oct 26, 2009 at 12:23 PM, Raymond Hettinger 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.
--
--Guido v
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 th
48 matches
Mail list logo
