On 30/04/20 3:32 am, Christopher Barker wrote:
I've wondered about Linked Lists for a while, but while there are many
versions on PyPi, I can't find one that seems to be mature and
maintained. Which seems to indicate that there isn't much demand for them.
I think this is probably because a
On 29/04/20 11:32 pm, Steven D'Aprano wrote:
My reasoning was that *eventually* for a big enough list, the cost of
making the copy would outweigh the cost of moving the items. I don't
know if my reasoning was valid or not,
I think it's not. They're both O(n) in the length of the list,
so at
On Apr 29, 2020, at 11:15, Tom Forbes wrote:
>
>> Thread 2 wakes up with the lock, calls the function, fills the cache, and
>> releases the lock.
>
> What exactly would the issue be with this:
>
> ```
> import functools
> from threading import Lock
>
> def once(func):
>sentinel =
> On Apr 29, 2020, at 11:15 AM, Tom Forbes wrote:
>
> What exactly would the issue be with this:
>
> ```
> import functools
> from threading import Lock
>
> def once(func):
>sentinel = object()
>cache = sentinel
>lock = Lock()
>
>@functools.wraps(func)
>def _wrapper():
> On Apr 29, 2020, at 12:02 PM, Christopher Barker wrote:
>
> On Apr 29, 2020, at 08:33, Christopher Barker wrote:
> > I've wondered about Linked Lists for a while, but while there are many
> > versions on PyPi, I can't find one that seems to be mature and maintained.
> > Which seems to
On 29/04/2020 20:54, Andrew Barnert via Python-ideas wrote:
On Apr 29, 2020, at 12:03, Christopher Barker
wrote:
Isn't much demand for a*generic* linked list. It would probably be
a good recipe though -- so users could have a starting point for
their custom version.
I think what would be
On Thu, Apr 30, 2020 at 5:56 AM Andrew Barnert via Python-ideas
wrote:
>
> On Apr 29, 2020, at 12:03, Christopher Barker wrote:
> >
> >
> > Isn't much demand for a *generic* linked list. It would probably be a good
> > recipe though -- so users could have a starting point for their custom
> >
On Apr 29, 2020, at 12:03, Christopher Barker wrote:
>
>
> Isn't much demand for a *generic* linked list. It would probably be a good
> recipe though -- so users could have a starting point for their custom
> version.
I think what would be really handy would be a HOWTO on linked lists that
On Apr 29, 2020, at 07:08, Barry Scott wrote:
>
>
>> On 28 Apr 2020, at 16:12, Rhodri James wrote:
>>
>>> On 28/04/2020 15:46, Brandt Bucher wrote:
>>> Thanks for weighing in, everybody.
>>> Over the course of the last week, it has become surprisingly clear that
>>> this change is
Thanks for all the details -- it really makes the point I was trying to
make.
On Apr 29, 2020, at 08:33, Christopher Barker wrote:
> > I've wondered about Linked Lists for a while, but while there are many
> versions on PyPi, I can't find one that seems to be mature and maintained.
> Which
On Apr 29, 2020, at 08:33, Christopher Barker wrote:
>
> I've wondered about Linked Lists for a while, but while there are many
> versions on PyPi, I can't find one that seems to be mature and maintained.
> Which seems to indicate that there isn't much demand for them.
I think there’s lots of
> Thread 2 wakes up with the lock, calls the function, fills the cache, and
> releases the lock.
What exactly would the issue be with this:
```
import functools
from threading import Lock
def once(func):
sentinel = object()
cache = sentinel
lock = Lock()
29.04.20 17:56, Ram Rachum пише:
Thanks everybody for your answers, and especially Ricky for finding this
note.
Please not that the optimization mentioned in the comment still keeps
the linear complexity for these operations. It just reduces the constant
multiplier.
On Tue, Apr 28, 2020 at 7:49 AM Brandt Bucher
wrote:
> With that in mind, I've started drafting one summarizing the discussion
> that took place here, and arguing for the addition of a boolean flag to the
> `zip` constructor.
Since you've gotten a few -1s, I'll add a +1 -- for reasons posted
On Wed, Apr 29, 2020 at 8:02 AM Ram Rachum wrote:
> Thanks everybody for your answers, and especially Ricky for finding this
> note.
>
which seems to indicate that if one were to implement this code more
efficiently, it would be considered for inclusion.
I will note that for the most part, the
Thanks everybody for your answers, and especially Ricky for finding this
note.
On Wed, Apr 29, 2020 at 2:20 PM Ricky Teachey wrote:
> I was playing around with deque today, and there were a couple of
>> operations I wanted to do, that can't really be done efficiently with deque
>> because of
> On 29 Apr 2020, at 12:36, remi.lape...@henki.fr wrote:
>
> Also, removing an element from a doubly-linked list is not a O(1) operation,
> it's O(n). It's O(1) once you have a pointer to the element but you have to
> iterate over the list to get it and that would take O(n) operations, so
>
> On 28 Apr 2020, at 16:12, Rhodri James wrote:
>
> On 28/04/2020 15:46, Brandt Bucher wrote:
>> Thanks for weighing in, everybody.
>> Over the course of the last week, it has become surprisingly clear that this
>> change is controversial enough to require a PEP.
>> With that in mind, I've
On Wed, Apr 29, 2020 at 01:42:05PM +0300, Ram Rachum wrote:
> I was iterating through items of a deque, and in some cases I wanted to
> delete an item that I've found.
Deleting items from a container while iterating through it is an
anti-pattern, easy to get wrong, prone to bugs, and in a
A deque is a data structure that exists outside of Python and the only
guarantee is that adding an element at the top or the front is O(1). Giving
more guarantee would force trade-offs and impose them to other implementations.
If you want fast deletion, you should use another data structure.
Hello,
On Wed, 29 Apr 2020 13:58:15 +0300
Ram Rachum wrote:
> On Wed, Apr 29, 2020 at 1:54 PM Paul Sokolovsky
> wrote:
>
> > If you want a different data structure, [...] implement such a
> > data structure
> >
>
> And if I wanted an answer like "it's the way that it is because it's
> the
>
> I was playing around with deque today, and there were a couple of
> operations I wanted to do, that can't really be done efficiently with deque
> because of its implementation.
>
> ...
>
> What do you think about adding [O(1) insert and remove] this to `deque`?
>
_collectionsmodule.c has this
On Wed, Apr 29, 2020 at 9:15 PM Chris Angelico wrote:
> I'm not seeing any evidence that this is a doubly-linked list. It
> might happen to be implemented using one in current versions of
> CPython, but that's not mandated anywhere.
(And it's not a pure DLL - it's a DLL of blocks of 64 elements
On Wed, Apr 29, 2020 at 9:01 PM Ram Rachum wrote:
> Is there a strategic decision to limit deque to certain operations of
> doubly-linked lists and not others? That would make sense. Is that decision
> written somewhere with the rationale behind it? That would be interesting to
> read.
>
On Wed, Apr 29, 2020 at 1:54 PM Paul Sokolovsky wrote:
> If you want a different data structure, [...] implement such a
> data structure
>
And if I wanted an answer like "it's the way that it is because it's the
way that it is" I wouldn't be posting on python-ideas.
Is there a strategic
Hello,
On Wed, 29 Apr 2020 13:42:05 +0300
Ram Rachum wrote:
> I was playing around with deque today, and there were a couple of
> operations I wanted to do, that can't really be done efficiently with
> deque because of its implementation.
>
> I was iterating through items of a deque, and in
I was playing around with deque today, and there were a couple of
operations I wanted to do, that can't really be done efficiently with deque
because of its implementation.
I was iterating through items of a deque, and in some cases I wanted to
delete an item that I've found. As far as I
On 28/04/2020 23:58, Andrew Barnert via Python-ideas wrote:
Really, we either need descriptors that can somehow work for globals
and class attributes (which is probably not solveable), or some brand
new language semantics that aren’t built on what’s already there. The
latter sounds like probably
What you want is to acquire a lock if the cache is empty, check if another
thread has filled the cache while you where waiting on the lock, call the
function, fill the cache and return.
I don’t see how you could implement that with two independent decorators
without locking all accesses
On Apr 28, 2020, at 16:25, Steven D'Aprano wrote:
>
> On Tue, Apr 28, 2020 at 11:45:49AM -0700, Raymond Hettinger wrote:
>
>> It seems like you would get just about everything you want with one line:
>>
>> once = lru_cache(maxsize=None)
>
> But is it thread-safe?
You can add thread
30 matches
Mail list logo
