Steven D'Aprano steve at pearwood.info writes:
If you can think of any other way to efficiently cycle over the elements
in a set, I'm all for it :)
How about for x in s?
Or if you want to cycle:
s = set('abc')
it = itertools.cycle(s)
next(it)
'a'
next(it)
'c'
next(it)
'b'
next(it)
Alexander Belopolsky wrote:
Odd indeed. My first reaction was: it is not needed because lists
support slicing, but when I tried to construct a list.get() using
slicing the best I could come up with was the following hack
def lget(l, i, v): return (l[i:] or [v])[0]
...
lget(range(10), 20,
[Guido wrote:]
- If sets were to grow an API to non-destructively access the object
stored in the set for a particular key, then dicts should have such a
method too.
- I still wish we could go back in time and unify sets and dicts, if
only to find out how that experiment would turn out.
+5.
[I wrote:]
If Python3 were to have this feature it would make it worth
migrating to
Sorry that may have sounded more harsh than I expected. If I had more
resources, I'd propose (and volunteer) a python3000 branch where any
and all who were disappointed at the *lack* of compatability changes
On Wed, Oct 28, 2009 at 12:34 PM, average dreamingforw...@gmail.com wrote:
[I wrote:]
If Python3 were to have this feature it would make it worth
migrating to
Sorry that may have sounded more harsh than I expected. If I had more
resources, I'd propose (and volunteer) a python3000 branch
geremy condra writes:
On Wed, Oct 28, 2009 at 12:34 PM, average dreamingforw...@gmail.com wrote:
[I wrote:]
If Python3 were to have this feature it would make it worth
migrating to
Sorry that may have sounded more harsh than I expected. If I had more
resources,
This is
[Stephen Turbull]
The resources available for language evolution have dried up;
*you* who want more language evolution are going to have to
supply them.
That's the idea I've been advocating- a code-first-jaw-later
approach and the sandbox to support it. Its not even that
hard to find where
Chris Bergstresser schrieb:
I like the proposed set.get() method, personally. list.get(index)
gets the item at that index, dict.get(key) gets the item associated
with that key, set.get() gets an item, but doesn't place any
guarantees on which item is returned.
Sorry to nitpick, but there
On Tue, Oct 27, 2009 at 11:06 AM, Georg Brandl g.bra...@gmx.net wrote:
Sorry to nitpick, but there is no list.get().
No? How ... odd. I guess it wouldn't have come up, but I was sure
there was a .get method which took an optional default parameter if
the index didn't exist, mirroring the
Chris Bergstresser schrieb:
On Tue, Oct 27, 2009 at 11:06 AM, Georg Brandl g.bra...@gmx.net wrote:
Sorry to nitpick, but there is no list.get().
No? How ... odd. I guess it wouldn't have come up, but I was sure
there was a .get method which took an optional default parameter if
the
On Tue, Oct 27, 2009 at 1:33 PM, Chris Bergstresser ch...@subtlety.com wrote:
On Tue, Oct 27, 2009 at 11:06 AM, Georg Brandl g.bra...@gmx.net wrote:
Sorry to nitpick, but there is no list.get().
No? How ... odd.
Odd indeed. My first reaction was: it is not needed because lists
support
John Arbash Meinel wrote:
res = heads(node1, node2)
if len(res) == 1:
# What is the 'obvious' way to get the node out?
I posit that there *isn't* an obvious way to get the single item out of
a 1-entry frozenset.
for x in res: break
list(res)[0]
set(res).pop()
iter(res).next()
[x for x in
[John Arbash Meine]
So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
faster than (iter(s).next()).
The first version uses direct calls for the for-loop opcodes.
The other two have to do functions/method look-up and
make a pure python function call (neither is very fast).
Martin v. Löwis writes:
res.get() would be a fairly obvious way to do it. Enough that I would
probably never have gone searching for any of the other answers. Though
personally, I think I would call it set.peek(), but the specific name
doesn't really matter to me.
Somebody
Why not allow that?
def any(self, predicate=lambda x: True, default=None)
for a in self:
if predicate(a):
break
else:
return default
return a
I'm +0 (given that I'm still skeptical about the need to have something
like
Hi,
I totally agree regarding the efficiency. Code that relies on a fast non-
removing .pop() probably has other worse bottlenecks that should be targetted
first.
This would, however, relief every programmer who needs this the first time in
his Python experience, to research how this could be
On Sun, Oct 25, 2009 at 1:48 AM, Nick Coghlan ncogh...@gmail.com wrote:
Terry Reedy wrote:
In this model, a
get() method, or even a __getitem__ with s[k] is k, is only natural.
No, if key and value were the same thing, the get method would be
nonesense, as Guido said. But since they are
Alexander Belopolsky wrote:
Here is an alternative idea on how storing interned objects in a set
can be supported. Currently set.add method returns None and had no
effect when set already has an object equal to the one being added. I
propose to consider changing that behavior to make set.add
All this talk of equivalence classes makes me dizzy. :-)
- If sets were to grow an API to non-destructively access the object
stored in the set for a particular key, then dicts should have such a
method too.
- Ditto for an API to non-destructively get an arbitrary element.
- I'm far from
On Mon, Oct 26, 2009 at 11:38 AM, Guido van Rossum gu...@python.org wrote:
- If sets were to grow an API to non-destructively access the object
stored in the set for a particular key, then dicts should have such a
method too.
- Ditto for an API to non-destructively get an arbitrary element.
Alex Martelli wrote:
Next(s) would seem good...
That does not work. It has to be next(iter(s)), and that has been tried
and eliminated because it is significantly slower.
Interesting. It depends a bit on the speed of tuple unpacking, but
presumably that is quite fast. On my system it is
On Oct 25, 2009, at 2:50 AM, Terry Reedy wrote:
Alex Martelli wrote:
Next(s) would seem good...
That does not work. It has to be next(iter(s)), and that has been
tried and eliminated because it is significantly slower.
But who cares about the speed of getting an arbitrary element from a
* James Y. Knight:
On Oct 25, 2009, at 2:50 AM, Terry Reedy wrote:
Alex Martelli wrote:
Next(s) would seem good...
That does not work. It has to be next(iter(s)), and that has been
tried and eliminated because it is significantly slower.
But who cares about the speed of getting an
Given Alexander's premise, I agree with your response. But his premise
is wrong. Python's current builtin set class maps abstract equivalence
classes to representative members. And this *is* useful. Mapping
arbitrary members of such classes to representative members, sometimes
called
If you actually care about that aspect of the semantics for a particular
application, it would be far clearer to use a full dict() and live with
the additional memory usage. While I can see how saving that
pointer-per-entry might make sense in some circumstances, for most I
would see it as a
On Mon, 26 Oct 2009 05:43:52 am Martin v. Löwis wrote:
What Alexander wants is that the set type also becomes useful for
storing canonical representations. I find that inappropriate, since
dicts already provide the one obvious way to do it.
Only because dicts came first in Python rather than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
Hmm, perhaps when using sets as work queues?
A number of comments:
- it's somewhat confusing to use a set as a *queue*, given
that it won't provide FIFO semantics.
- there are more appropriate and direct container
We were using sets to track the tips of a graph, and to compare whether
one node was an ancestor of another one. We were caching that answer
into frozensets, since that made them immutable. If
res = heads(node1, node2)
if len(res) == 1:
# What is the 'obvious' way to get the node out?
Ben Finney writes:
Steven D'Aprano st...@pearwood.info writes:
get is such a generic term that I don't believe that is a problem.
The problem above is made less problematic by the fact that the function
signature (e.g. 'foo_dict.get(key)') clarifies the answer to the
question get
Ben Finney wrote:
Which then raises the question “what part of the set does it get?”,
which the function signature does nothing to answer. I'm proposing that
a no-parameters ‘set.get’ is needlessly confusing to think about.
The fact that set.get() is just set.pop() without removing the result
On 24/10/2009, Nick Coghlan ncogh...@gmail.com wrote:
Ben Finney wrote:
Which then raises the question “what part of the set does it get?”,
which the function signature does nothing to answer. I'm proposing that
a no-parameters ‘set.get’ is needlessly confusing to think about.
The fact that
Hi,
I agree. But, here are the pros/cons collected from the recent list repsonses:
Pro:
- more readable
- newbies will encounter one of the fastest solution (.get()) before trying
slower first solutions like (iter(set).next())
Cons:
- no name consensus. get() getany() arbitrary() ?
- BDFL
On Sat, 24 Oct 2009 08:12:26 pm Martin (gzlist) wrote:
On 24/10/2009, Nick Coghlan ncogh...@gmail.com wrote:
Ben Finney wrote:
Which then raises the question “what part of the set does it
get?”, which the function signature does nothing to answer. I'm
proposing that a no-parameters
Hi,
someone on this list mentioned that much of the s.get() time is spend on the
name lookup for get(). That is indeed the case:
===
from timeit import *
stats = [for i in xrange(1000): iter(s).next() ,
for i in xrange(1000): \n\tfor x in s: \n\t\tbreak,
for
On Fri, Oct 23, 2009 at 6:46 PM, Steven D'Aprano st...@pearwood.info wrote:
On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
..
fwiw, I think the use case for this is sufficiently rare that it does
not need a separate method just for this purpose.
And yet it keeps coming up, again and
On Sat, Oct 24, 2009 at 10:34 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
To me, however, a set seems to be a container that is a specialization
of a dict with values and keys being the same.
That's absurd; the mapping provides nothing useful.
--
--Guido van Rossum
PS. My
Steven D'Aprano wrote:
On Sat, 24 Oct 2009 08:12:26 pm Martin (gzlist) wrote:
There's a different proposed meaning for `set.get` that's been
discussed on python-dev before:
http://mail.python.org/pipermail/python-dev/2009-April/088128.html
For that case, I think the OP was mistaken
Guido van Rossum wrote:
On Sat, Oct 24, 2009 at 10:34 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
To me, however, a set seems to be a container that is a specialization
of a dict with values and keys being the same.
That's absurd; the mapping provides nothing useful.
Alexander Belopolsky wrote:
On Fri, Oct 23, 2009 at 6:46 PM, Steven D'Aprano st...@pearwood.info wrote:
On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
..
fwiw, I think the use case for this is sufficiently rare that it does
not need a separate method just for this purpose.
And yet it
On Fri, Oct 23, 2009 at 11:04, Vitor Bosshard algor...@gmail.com wrote:
I see this as being useful for frozensets as well, where you can't get
an arbitrary element easily due to the obvious lack of .pop(). I ran
into this recently, when I had a frozenset that I knew had 1 element
(it was the
Adam Olsen wrote:
On Fri, Oct 23, 2009 at 11:04, Vitor Bosshard algor...@gmail.com wrote:
I see this as being useful for frozensets as well, where you can't get
an arbitrary element easily due to the obvious lack of .pop(). I ran
into this recently, when I had a frozenset that I knew had 1
Next(s) would seem good...
Alex
Sent from my iPhone
On Oct 24, 2009, at 6:47 PM, John Arbash Meinel john.mei...@canonical.com
wrote:
Adam Olsen wrote:
On Fri, Oct 23, 2009 at 11:04, Vitor Bosshard algor...@gmail.com
wrote:
I see this as being useful for frozensets as well, where you
Terry Reedy wrote:
In this model, a
get() method, or even a __getitem__ with s[k] is k, is only natural.
No, if key and value were the same thing, the get method would be
nonesense, as Guido said. But since they are not, since the implict key
is an abstract class, retrieving the
Hi,
recently I wrote an algorithm, in which very often I had to get an arbitrary
element from a set without removing it.
Three possibilities came to mind:
1.
x = some_set.pop()
some_set.add(x)
2.
for x in some_set:
break
3.
x = iter(some_set).next()
Of course, the third should
On Fri, 23 Oct 2009 08:32:45 pm Willi Richert wrote:
Hi,
recently I wrote an algorithm, in which very often I had to get an
arbitrary element from a set without removing it.
Three possibilities came to mind:
...
Of course, the third should be the fastest.
If you need one or more items
2009/10/23 Willi Richert w.rich...@gmx.net:
Hi,
recently I wrote an algorithm, in which very often I had to get an arbitrary
element from a set without removing it.
Three possibilities came to mind:
1.
x = some_set.pop()
some_set.add(x)
2.
for x in some_set:
break
3.
x =
Vitor Bosshard wrote:
2009/10/23 Willi Richert w.rich...@gmx.net:
Hi,
recently I wrote an algorithm, in which very often I had to get an arbitrary
element from a set without removing it.
Three possibilities came to mind:
1.
x = some_set.pop()
some_set.add(x)
2.
for x in some_set:
2009/10/23 John Arbash Meinel john.arbash.mei...@gmail.com:
I was pretty surprised that it was 30% faster than for x in s: pass. I
assume it has something to do with a potential else: statement?
I'd imagine it's actually because it has to call next() a second time
and deal with the
Willi Richert wrote:
recently I wrote an algorithm, in which very often I had to get an arbitrary
element from a set without removing it.
See this discussion:
http://comments.gmane.org/gmane.comp.python.ideas/5606
Stefan
___
Python-Dev mailing
John Arbash Meinel wrote:
So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
faster than (iter(s).next()).
I was pretty surprised that it was 30% faster than for x in s: pass. I
assume it has something to do with a potential else: statement?
for x in s: pass
iterates through
Terry Reedy wrote:
John Arbash Meinel wrote:
So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
faster than (iter(s).next()).
I was pretty surprised that it was 30% faster than for x in s: pass. I
assume it has something to do with a potential else: statement?
for x in s:
Hi,
surprised about the performance of for/break provided by Vitor, I did some
more testing. It revealed that indeed we can forget the get() (which was
implemented as a stripped down pop()):
from timeit import *
stats = [for i in xrange(1000): iter(s).next() ,
for i in
On Sat, 24 Oct 2009 07:11:57 am John Arbash Meinel wrote:
The point of my test was that it was a set with a *single* item, and
'break' was 30% faster than 'pass'. Which was surprising.
Not really. See below.
Certainly
the difference is huge if there are 10k items in the set.
Earlier you
On Sat, 24 Oct 2009 07:53:24 am Willi Richert wrote:
Hi,
surprised about the performance of for/break provided by Vitor, I did
some more testing. It revealed that indeed we can forget the get()
(which was implemented as a stripped down pop()):
I don't understand that conclusion. According
Steven D'Aprano st...@pearwood.info writes:
On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
fwiw, I think the use case for this is sufficiently rare that it
does not need a separate method just for this purpose.
And yet it keeps coming up, again and again... obviously people using
sets
On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
Steven D'Aprano st...@pearwood.info writes:
On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
fwiw, I think the use case for this is sufficiently rare that it
does not need a separate method just for this purpose.
And yet it keeps
Steven D'Aprano st...@pearwood.info writes:
On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
Steven D'Aprano st...@pearwood.info writes:
The lack of get() in sets and frozensets is sounding more and more
to me like the victory of purity over practicality.
What would be the input to
On Sat, 24 Oct 2009 02:02:48 pm Ben Finney wrote:
Steven D'Aprano st...@pearwood.info writes:
On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
Steven D'Aprano st...@pearwood.info writes:
The lack of get() in sets and frozensets is sounding more and
more to me like the victory of
Steven D'Aprano st...@pearwood.info writes:
On Sat, 24 Oct 2009 02:02:48 pm Ben Finney wrote:
I would expect a parameter-less ‘set.get’ to get the set. Not
terribly useful, but the name and function signature doesn't suggest
anything else.
You already have the set. Why would you need a
59 matches
Mail list logo
