Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 1:28 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > Will you engage with me over e-mail to discuss the Locker > > implementation I'm developing? Aaron > > I really can't, sorry. I'm finding it hard enough to follow over the > newsgroup. If you just ha

Re: removeall() in list

2008-01-12 Thread Paul Rubin
[EMAIL PROTECTED] writes: > Will you engage with me over e-mail to discuss the Locker > implementation I'm developing? Aaron I really can't, sorry. I'm finding it hard enough to follow over the newsgroup. If you just have a single one of these lists, it's probably simplest to do what Frederik L

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 1:03 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > > Nothing else should have direct access to the list. > > Impossible to guarantee in Python. If you do, the reference to you does. > > Well, ok. Nothing else should USE that access. Ah, very agreed.

Re: removeall() in list

2008-01-12 Thread Paul Rubin
[EMAIL PROTECTED] writes: > > Nothing else should have direct access to the list. > Impossible to guarantee in Python. If you do, the reference to you does. Well, ok. Nothing else should USE that access. -- http://mail.python.org/mailman/listinfo/python-list

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 12:26 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > 2) List is referenced by others; concurrent modifications may be going > > on; can not replace it. Can I make asynchronous modifications and > > merge the changes, SCM-style? > > Nothing else should h

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 12:26 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > 2) List is referenced by others; concurrent modifications may be going > > on; can not replace it. Can I make asynchronous modifications and > > merge the changes, SCM-style? > > Nothing else should h

Re: removeall() in list

2008-01-12 Thread Paul Rubin
[EMAIL PROTECTED] writes: > 2) List is referenced by others; concurrent modifications may be going > on; can not replace it. Can I make asynchronous modifications and > merge the changes, SCM-style? Nothing else should have direct access to the list. > 3) Dictionary returns non-static order; ord

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 11:22 am, Rhamphoryncus <[EMAIL PROTECTED]> wrote: > On Jan 12, 1:37 am, [EMAIL PROTECTED] wrote: > > > > > On Jan 11, 8:04 pm, Paul Rubin wrote: > > > > [EMAIL PROTECTED] writes: > > > > Could you: > > > > > lockerA= Locker( listA, listB ) > > > > lockerA.op(

Re: removeall() in list

2008-01-12 Thread Rhamphoryncus
On Jan 12, 1:37 am, [EMAIL PROTECTED] wrote: > On Jan 11, 8:04 pm, Paul Rubin wrote: > > > > > [EMAIL PROTECTED] writes: > > > Could you: > > > > lockerA= Locker( listA, listB ) > > > lockerA.op( listB.reverse ) > > > lockerA.op( listA.pop ) > > > > Where lockerA ops acqu

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 8:04 am, [EMAIL PROTECTED] wrote: > On Jan 11, 5:26 pm, Paul Rubin wrote: > > > [EMAIL PROTECTED] writes: > > > 1. Put a single thread in charge of the list, and communicate with it > > by message passing through Queues. To get X out of the list, you'd > > sen

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 11, 5:26 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > 1. Put a single thread in charge of the list, and communicate with it > by message passing through Queues. To get X out of the list, you'd > send the mutator thread a message asking for removal. The m

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 3:51 am, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > I'm writing an NxN observer pattern, mostly for my own personal > > exploration. Two threads -might- be calling 'Disconnect' at the same > > time, and I can't even guarantee that the function runs properly.

Re: removeall() in list

2008-01-12 Thread Fredrik Lundh
[EMAIL PROTECTED] wrote: > I'm writing an NxN observer pattern, mostly for my own personal > exploration. Two threads -might- be calling 'Disconnect' at the same > time, and I can't even guarantee that the function runs properly. > > for emelem in [ e for e in emlist if e.func is func ]: >

Re: removeall() in list

2008-01-12 Thread Paul Rubin
[EMAIL PROTECTED] writes: > > I'm writing an NxN observer pattern, mostly for my own personal > > exploration. Two threads -might- be calling 'Disconnect' at the same > > time, and I can't even guarantee that the function runs properly. I think the Pythonic way to do this is have the targets com

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 12, 2:37 am, [EMAIL PROTECTED] wrote: > On Jan 11, 8:04 pm, Paul Rubin wrote: > > > > > [EMAIL PROTECTED] writes: > > > Could you: > > > > lockerA= Locker( listA, listB ) > > > lockerA.op( listB.reverse ) > > > lockerA.op( listA.pop ) > > > > Where lockerA ops acqu

Re: removeall() in list

2008-01-12 Thread castironpi
On Jan 11, 8:04 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > Could you: > > > lockerA= Locker( listA, listB ) > > lockerA.op( listB.reverse ) > > lockerA.op( listA.pop ) > > > Where lockerA ops acquire the locks on all its threads? > > I don't understand that que

Re: removeall() in list

2008-01-11 Thread Paul Rubin
[EMAIL PROTECTED] writes: > Could you: > > lockerA= Locker( listA, listB ) > lockerA.op( listB.reverse ) > lockerA.op( listA.pop ) > > Where lockerA ops acquire the locks on all its threads? I don't understand that question. The main thing to understand is that multi-threaded programming is com

Re: removeall() in list

2008-01-11 Thread castironpi
On Jan 11, 6:17 pm, [EMAIL PROTECTED] wrote: > On Jan 11, 5:51 pm, Paul Rubin wrote: > > > > > [EMAIL PROTECTED] writes: > > > listA.op( insert, x ) > > > listA.op( remove, x ) > > > Sure, there are various ways you can make the code look uniform. What > > gets messy is

Re: removeall() in list

2008-01-11 Thread castironpi
On Jan 11, 5:51 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > listA.op( insert, x ) > > listA.op( remove, x ) > > Sure, there are various ways you can make the code look uniform. What > gets messy is if you want to (say) operate on several lists at the > same tim

Re: removeall() in list

2008-01-11 Thread Paul Rubin
[EMAIL PROTECTED] writes: > > 2. Associate a lock with the list. Anything wanting to access the > > list should acquire the lock, do its stuff, then release the lock. > > This gets confusing after a while. > > To keep it generic, how about: > > listA.op( insert, x ) > listA.op( remove, x ) Sure

Re: removeall() in list

2008-01-11 Thread castironpi
On Jan 11, 5:43 pm, [EMAIL PROTECTED] wrote: > On Jan 11, 5:26 pm, Paul Rubin wrote: > > > [EMAIL PROTECTED] writes: > > > This function just wants X out of the list. It doesn't matter if this > > > happens before, during, or after something else; so long as it happens.

Re: removeall() in list

2008-01-11 Thread castironpi
On Jan 11, 5:26 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > This function just wants X out of the list. It doesn't matter if this > > happens before, during, or after something else; so long as it happens. > > 2. Associate a lock with the list. Anything wantin

Re: removeall() in list

2008-01-11 Thread Paul Rubin
[EMAIL PROTECTED] writes: > This function just wants X out of the list. It doesn't matter if this > happens before, during, or after something else; so long as it happens. If you're asking in a general way how to do something like that, there are several basic methods: 1. Put a single thread in

Re: removeall() in list

2008-01-11 Thread castironpi
On Jan 11, 2:57 pm, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > Any ideas for a thread-safe list.removeall( X ): removing all > > occurrences of X within list L, when L might be modified concurrently? > > That way lies madness. Do something sensible instead. Put a

Re: removeall() in list

2008-01-11 Thread Paul Rubin
[EMAIL PROTECTED] writes: > Any ideas for a thread-safe list.removeall( X ): removing all > occurrences of X within list L, when L might be modified concurrently? That way lies madness. Do something sensible instead. Put a lock around the list, or put all mutators for the list into a single thre