On Mar 31, 11:06 am, pataphor wrote:
> On Tue, 31 Mar 2009 06:03:13 -0700 (PDT)
>
> Alex_Gaynor wrote:
> > My inclination would be to more or less *just* have it implement the
> > set API, the way ordered dict does in 2.7/3.1.
>
> As far as I can tell all that would be needed is read/write access
On Tue, 31 Mar 2009 06:03:13 -0700 (PDT)
Alex_Gaynor wrote:
> My inclination would be to more or less *just* have it implement the
> set API, the way ordered dict does in 2.7/3.1.
As far as I can tell all that would be needed is read/write access to
two key variables: The iterator start position
On Mar 31, 5:52 am, pataphor wrote:
> On Tue, 31 Mar 2009 10:33:26 +0200
>
> pataphor wrote:
> > On Mon, 30 Mar 2009 19:57:39 -0700 (PDT)
> > Alex_Gaynor wrote:
>
> > > I really like the Ordered Set class(I've been thinking about one
> > > ever since ordered dict hit the std lib), is there any a
On Tue, 31 Mar 2009 10:33:26 +0200
pataphor wrote:
> On Mon, 30 Mar 2009 19:57:39 -0700 (PDT)
> Alex_Gaynor wrote:
>
> > I really like the Ordered Set class(I've been thinking about one
> > ever since ordered dict hit the std lib), is there any argument
> > against adding one to the collections
On Mon, 30 Mar 2009 19:57:39 -0700 (PDT)
Alex_Gaynor wrote:
> I really like the Ordered Set class(I've been thinking about one ever
> since ordered dict hit the std lib), is there any argument against
> adding one to the collections module? I'd be willing to write a PEP
> up for it.
Suppose the
On Mar 30, 12:27 pm, pataphor wrote:
> On Mon, 30 Mar 2009 03:30:04 -0500
>
> Nick Craig-Wood wrote:
> > >>> class Node(object):
> > ... __slots__ = ["prev", "next", "this"]
> > ... def __init__(self, prev, next, this):
> > ... self.prev = prev
> > ... self.next = next
> >
On Mon, 30 Mar 2009 03:30:04 -0500
Nick Craig-Wood wrote:
> >>> class Node(object):
> ... __slots__ = ["prev", "next", "this"]
> ... def __init__(self, prev, next, this):
> ... self.prev = prev
> ... self.next = next
> ... self.this = this
[...]
> So the Node cla
Aahz wrote:
> I find the trick of using a Python list to store the doubly-linked
> list difficult to understand (as opposed to the usual mechanism of a
> node class). I understand why it was done (time and space
> efficiency), but I also still feel emotionally that it's somewhat
> sick and perver
On Mar 28, 3:33 am, "Gabriel Genellina"
wrote:
> En Thu, 26 Mar 2009 12:20:17 -0300, Scott David Daniels
> escribió:
>
> > (2) Why, oh why, do people feel so comforted adding double_underscores
> > to data structures?
Probably because other authors feel too comfortable using single
unders
In article <01d457aa$0$17208$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
>On Fri, 20 Mar 2009 11:50:28 -0700, Scott David Daniels wrote:
>> Raymond Hettinger wrote:
>>> [Aahz]
The doubly-linked list part is what's sick and perverted.
>>>
>>> The doubly-linked list part is what g
En Thu, 26 Mar 2009 12:20:17 -0300, Scott David Daniels
escribió:
(2) Why, oh why, do people feel so comforted adding double_underscores
to data structures? If I want to inherit from your mapping in order
to log the attempts to discard a key not actually in the set, I
have to
pataphor wrote:
Raymond Hettinger wrote:
Right. Here's a link to a weakref version (though I think the
previous __del__ version also does the trick):
http://code.activestate.com/recipes/576696/
Interesting. But how about this one? Does it also have the reference
problem? By the way col
Raymond Hettinger wrote:
Right. Here's a link to a weakref version (though I think the
previous __del__ version also does the trick):
http://code.activestate.com/recipes/576696/
Interesting. But how about this one? Does it also have the reference
problem? By the way collections.MutableS
[Terry Reedy]
> I think the idea was 2 weakrefs and 1 normal ref instead of 3 normal refs.
Right. Here's a link to a weakref version (though I think the
previous __del__ version also does the trick):
http://code.activestate.com/recipes/576696/
Raymond
--
http://mail.python.org/mailman/lis
Steven D'Aprano wrote:
On Fri, 20 Mar 2009 11:50:28 -0700, Scott David Daniels wrote:
Raymond Hettinger wrote:
[Aahz]
The doubly-linked list part is what's sick and perverted.
The doubly-linked list part is what gives it big-oh running times the
same as regular sets. If the underlying seque
On Fri, 20 Mar 2009 11:50:28 -0700, Scott David Daniels wrote:
> Raymond Hettinger wrote:
>> [Aahz]
>>> The doubly-linked list part is what's sick and perverted.
>>
>> The doubly-linked list part is what gives it big-oh running times the
>> same as regular sets. If the underlying sequence is sto
On Mar 20, 1:50 pm, Scott David Daniels wrote:
> Raymond Hettinger wrote:
> > [Aahz]
> >> The doubly-linked list part is what's sick and perverted.
>
> > The doubly-linked list part is what gives it big-oh running
> > times the same as regular sets. If the underlying sequence
> > is stored as a l
[Scott David Daniels]
> The double-linked list part could be done with weakrefs and
> perhaps Aahz would relax a bit.
Am thinking that the __del__() takes care of business.
The clear() operation removes the links and all references
to them (including circular).
Raymond
--
http://mail.python.org
Raymond Hettinger wrote:
[Aahz]
The doubly-linked list part is what's sick and perverted.
The doubly-linked list part is what gives it big-oh running
times the same as regular sets. If the underlying sequence
is stored as a list, then deletion goes from O(1) to O(n).
If the insertion times ar
[Aahz]
> The doubly-linked list part is what's sick and perverted.
The doubly-linked list part is what gives it big-oh running
times the same as regular sets. If the underlying sequence
is stored as a list, then deletion goes from O(1) to O(n).
If the insertion times are recorded in a dictionary,
In article ,
Nigel Rantor wrote:
>Aahz wrote:
>> In article
>> <9a5d59e1-2798-4864-a938-9b39792c5...@s9g2000prg.googlegroups.com>,
>> Raymond Hettinger wrote:
>>>
>>> Here's a new, fun recipe for you guys:
>>>
>>> http://code.activestate.com/recipes/576694/
>>
>> That is *sick* and perverted.
Aahz wrote:
In article <9a5d59e1-2798-4864-a938-9b39792c5...@s9g2000prg.googlegroups.com>,
Raymond Hettinger wrote:
Here's a new, fun recipe for you guys:
http://code.activestate.com/recipes/576694/
That is *sick* and perverted.
I'm not sure why.
Would it be less sick if it had been call
In article <9a5d59e1-2798-4864-a938-9b39792c5...@s9g2000prg.googlegroups.com>,
Raymond Hettinger wrote:
>
>Here's a new, fun recipe for you guys:
>
>http://code.activestate.com/recipes/576694/
That is *sick* and perverted.
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncr
Here's a new, fun recipe for you guys:
http://code.activestate.com/recipes/576694/
Enjoy,
Raymond
--
http://mail.python.org/mailman/listinfo/python-list
Bengt Richter wrote:
> Perhaps newbies should be advised that
>
> [x for x in l1 if x in set(l2)]
But the resulting list is a representative of bag not a set ( contains
multiple occurrences of elements ):
>>> [x for x in [3, 3] if s in Set([3])]
[3,3]
Same with Raymonds solution:
>>> filt
On 2/12/06, Felipe Almeida Lessa <[EMAIL PROTECTED]> wrote:
> Em Dom, 2006-02-12 às 23:15 -0500, Steve Holden escreveu:
> > Given that Python 2.4 doesn't even perform simple constant folding for
> > arithmetic expressions
> > [snip]
>
> May I ask why doesn't it perform such optimization? Is there a
Felipe Almeida Lessa wrote:
> Em Dom, 2006-02-12 às 23:51 -0500, Steve Holden escreveu:
>
>>The basic answer is that so far no developer has felt it worthwhile to
>>expend time on adding these optimizations.
>
>
> I always thought these small optimizations could lead Python to be
> faster overa
Delaney, Timothy (Tim) wrote:
> Adding such optimisations to Python may improve it's benchmark scores,
Blegh! Time to give myself a good kicking!
Tim Delaney
--
http://mail.python.org/mailman/listinfo/python-list
Em Dom, 2006-02-12 às 23:51 -0500, Steve Holden escreveu:
> The basic answer is that so far no developer has felt it worthwhile to
> expend time on adding these optimizations.
I always thought these small optimizations could lead Python to be
faster overall. I remember about this every time I see
Steve Holden wrote:
> The basic answer is that so far no developer has felt it worthwhile to
> expend time on adding these optimizations.
Mainly because it's rare to find such constructs in anything except
contrived examples ... Nearly every time you use a literal, it's being
added to (subtracted
Felipe Almeida Lessa wrote:
> Em Dom, 2006-02-12 às 23:15 -0500, Steve Holden escreveu:
>
>>Given that Python 2.4 doesn't even perform simple constant folding for
>>arithmetic expressions
>>[snip]
>
>
> May I ask why doesn't it perform such optimization? Is there any special
> difficulties in d
Em Dom, 2006-02-12 às 23:15 -0500, Steve Holden escreveu:
> Given that Python 2.4 doesn't even perform simple constant folding for
> arithmetic expressions
> [snip]
May I ask why doesn't it perform such optimization? Is there any special
difficulties in doing so with the Python compiler?
Also, I
Alex Martelli wrote:
> Bengt Richter <[EMAIL PROTECTED]> wrote:
>...
>
>>>Personally, I'd always use (depending on guesses regarding lengths of
>>>lists) [x for x in l1 if x in l2] or the setified equivalent, of course.
>>>
>>
>>Perhaps newbies should be advised that
>>
>>[x for x in l1 if
Bengt Richter <[EMAIL PROTECTED]> wrote:
...
> >Personally, I'd always use (depending on guesses regarding lengths of
> >lists) [x for x in l1 if x in l2] or the setified equivalent, of course.
> >
> Perhaps newbies should be advised that
>
> [x for x in l1 if x in set(l2)]
>
> is not a (w
On Sat, 11 Feb 2006 10:24:04 -0800, [EMAIL PROTECTED] (Alex Martelli) wrote:
>Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> ...
>> The intersection step is unnecessary, so the answer can be simplified a
>> bit:
>>
>> >>> filter(set(l2).__contains__, l1)
>> [5, 3]
>> >>> filter(set(l1).__contai
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
...
> The intersection step is unnecessary, so the answer can be simplified a
> bit:
>
> >>> filter(set(l2).__contains__, l1)
> [5, 3]
> >>> filter(set(l1).__contains__, l2)
> [3, 5]
...and if one has time to waste, "setification" being only an
opti
Raymond Hettinger wrote:
> The intersection step is unnecessary, so the answer can be simplified a
> bit:
>
> >>> filter(set(l2).__contains__, l1)
> [5, 3]
> >>> filter(set(l1).__contains__, l2)
> [3, 5]
stand corrected.
--
http://mail.python.org/mailman/listinfo/python-list
[Amit Khemka]
> > Hello, Is there a *direct* way of doing set operations on lists which
> > preserve the order of the input lists ?
> > For Ex. l1 = [1, 5, 3, 2, 4, 7]
> > l2 = [3, 5, 10]
> >
> > and (l1 intersect l2) returns [5, 3] (and (l2 intersect l1)
[bonono]
> what d
Amit Khemka wrote:
> Hello, Is there a *direct* way of doing set operations on lists which
> preserve the order of the input lists ?
Nope
> For Ex. l1 = [1, 5, 3, 2, 4, 7]
> l2 = [3, 5, 10]
>
> and (l1 intersect l2) returns [5, 3] (and (l2 intersect l1)
> returns [3, 5])
Amit Khemka wrote:
> Hello, Is there a *direct* way of doing set operations on lists which
> preserve the order of the input lists ?
> For Ex. l1 = [1, 5, 3, 2, 4, 7]
> l2 = [3, 5, 10]
>
> and (l1 intersect l2) returns [5, 3] (and (l2 intersect l1)
> returns [3, 5])
>
what
Hello, Is there a *direct* way of doing set operations on lists which
preserve the order of the input lists ?
For Ex. l1 = [1, 5, 3, 2, 4, 7]
l2 = [3, 5, 10]
and (l1 intersect l2) returns [5, 3] (and (l2 intersect l1)
returns [3, 5])
thanks in advance,
amit.
--
Ami
41 matches
Mail list logo
