On Fri, 6 Nov 2009 10:52:54 am Yuvgoog Greenle wrote:
> On Fri, Nov 6, 2009 at 1:17 AM, James Y Knight wrote:
> > Is this thread over yet?
>
> Sorry, I just had to point out that pop/add has a side effect that
> would be apparent on a set that multiple threads access - it loses an
> item and then
On Thu, Nov 5, 2009 at 11:21 PM, John Arbash Meinel
wrote:
> geremy condra wrote:
>> On Thu, Nov 5, 2009 at 4:09 PM, Alexander Belopolsky
>> wrote:
>>> On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser
>>> wrote:
.. and "x = iter(s).next()" raises a StopIteration
exception.
>>> And t
geremy condra wrote:
> On Thu, Nov 5, 2009 at 4:09 PM, Alexander Belopolsky
> wrote:
>> On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser
>> wrote:
>>> .. and "x = iter(s).next()" raises a StopIteration
>>> exception.
>> And that's why the documented recipe should probably recommend
>> next(ite
On Thu, Nov 5, 2009 at 6:30 PM, geremy condra wrote:
> I'm testing the speed because the claim was made that the pop/add
> approach was inefficient. Here's the full quote:
>
>> The obvious way, for newcomers, of achieving the effect is:
>>
>> x = s.pop()
>> s.add(x)
>>
>> ... and that's simpl
On Thu, Nov 5, 2009 at 6:17 PM, James Y Knight wrote:
> On Nov 5, 2009, at 6:04 PM, geremy condra wrote:
>>
>> Perhaps my test is flawed in some way?
>
> Yes: you're testing the speed of something that makes absolutely no sense to
> do in a tight loop, so *who the heck cares how fast any way of do
On Fri, Nov 6, 2009 at 1:17 AM, James Y Knight wrote:
>
> Is this thread over yet?
>
>
Sorry, I just had to point out that pop/add has a side effect that would be
apparent on a set that multiple threads access - it loses an item and then
gets it back. Sounds like a sleeper race condition that's g
On Nov 5, 2009, at 6:04 PM, geremy condra wrote:
Perhaps my test is flawed in some way?
Yes: you're testing the speed of something that makes absolutely no
sense to do in a tight loop, so *who the heck cares how fast any way
of doing it is*!
Is this thread over yet?
James
___
On Thu, Nov 5, 2009 at 4:09 PM, Alexander Belopolsky
wrote:
> On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser wrote:
>> .. and "x = iter(s).next()" raises a StopIteration
>> exception.
>
> And that's why the documented recipe should probably recommend
> next(iter(s), default) instead. Especia
[Chris Bergstresser]
> Clearly, I'll need to write up the PEP.
Why not write a short, fast get_first() function for your utils directory and
be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for somethi
On Thu, Nov 5, 2009 at 3:21 PM, "Martin v. Löwis" wrote:
> There are two ways
>
> a) write a library that provides what you want, publish it on PyPI,
> and report back in a few years of how many users your library has,
> what they use it for, and why it should become builtin
This clearly
>I feel pretty strongly that it's a wart in the language, and a
> sufficiently strong one that it should be remedied. I'm happy to
> champion it, but haven't the faintest idea what that entails.
There are two ways
a) write a library that provides what you want, publish it on PyPI,
and rep
On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser wrote:
> .. and "x = iter(s).next()" raises a StopIteration
> exception.
And that's why the documented recipe should probably recommend
next(iter(s), default) instead. Especially because iter(s).next() is
not even valid code in 3.0.
On Wed, Nov 4, 2009 at 7:07 PM, Raymond Hettinger wrote:
> [Steven D'Aprano]
>>> Anyway, given the level of opposition to the suggestion, I'm no longer
>>> willing to carry the flag for it. If anyone else -- perhaps the OP --
>>> feels they want to take it any further, be my guest.
I feel pret
Eric Smith wrote:
Raymond Hettinger wrote:
Summarizing my opposition to a new set method:
1) there already are at least two succinct ways to get the same effect
2) those ways work with any container, not just sets
3) set implementations in other languages show that this isn't needed.
4) there is
Raymond Hettinger wrote:
Summarizing my opposition to a new set method:
1) there already are at least two succinct ways to get the same effect
2) those ways work with any container, not just sets
3) set implementations in other languages show that this isn't needed.
4) there is value to keeping t
[Steven D'Aprano]
Anyway, given the level of opposition to the suggestion, I'm no longer
willing to carry the flag for it. If anyone else -- perhaps the OP --
feels they want to take it any further, be my guest.
[geremy condra]
I've said before that I'd like there to be one, standard way of
Personally, I have found it useful in doco I write to have a section on
"Common Tasks", with recommended/suggested examples of how to do them and
short rationale for the chosen method. It seems to me that if .pick()
is frequently desired and "None of the standard solutions are obvious
or easily di
Am Sonntag, 1. November 2009 12:21:15 schrieben Sie:
> It seems that even those originally asking for set retrieval have gone
> silent
Nope. Stilll following and waiting for the verdict of the community after
having filed the corpus delicti [1]
wr
[1]: http://bugs.python.org/issue7212
__
It seems that even those originally asking for set retrieval have gone
silent, so I guess this isn't going anywhere.
However, for the benefit of future discussions (because I'm sure this
question will be raised again), I'd like to answer a couple of points
raised by Stephen.
On Sat, 31 Oct 200
Steven D'Aprano writes:
> The usual technique people tend to come up with is:
>
> x = s.pop()
> s.add(x)
>
> Which strikes many people (including myself) as inelegant. Surely "get
> an element" is a more fundamental operation than "get an element and
> remove it"?
Not in a literal urn
Steven D'Aprano wrote:
>> So you want to introduce additional, hidden state to sets? (to make
>> sure that successive invocations return different values)
>
> If you can think of any other way to efficiently cycle over the elements
> in a set, I'm all for it :)
for x in itertools.cycle(s):
# t
On Fri, 30 Oct 2009 03:00:27 pm Raymond Hettinger wrote:
[skipping to the last paragraph]
> Sorry for so many questions
Don't be sorry. These are good questions, and I'll try to answer them.
But keep in mind that this isn't my proposal -- I vary between +0 and
+1 on the proposal depending on t
[Steven D'Aprano]
The suggested
semantics for set.get() with no arguments, as I understand them, are:
(1) it will only fail if the set is empty;
Just like next() except that next() gives you the option to supply a default
and can be used on any iterator (perhaps iter(s) or itertools.cycle(s)
On Tue, Oct 27, 2009 at 3:49 PM, Raymond Hettinger wrote:
>
> [geremy condra]
>>
>> Was it ever decided whether this would fall under the moratorium?
>
> Decided isn't the right word:
> http://mail.python.org/pipermail/python-dev/2009-October/093373.html
>
I'm unclear- does that imply that this
[geremy condra]
Was it ever decided whether this would fall under the moratorium?
Decided isn't the right word:
http://mail.python.org/pipermail/python-dev/2009-October/093373.html
FWIW, I'm a strong -1 on both proposals.
Just add a short get_one() function and a get_equivalent() recipe
to y
25 matches
Mail list logo
