[Python-Dev] New PEP: 319

[Michel Pelletier]

>> I don't see how this can possibly work.  It looks like self.counter is
>> an int, so the statement
>>     synchronize self.counter: ...
>> must be using some particular int (say, 3) for purposes of
>> synchronization.  What sense does this make?
>
> Hmm good point, integer objects are a special case, they  are shared and
> are thus a bad example.  Perhaps only instances should be synchronizable.
>
>>  (and where can you store
>> the lock, since an int is immutable and can't have new attributes
>> created?)
>
> that's up to the implementation.  Lock association does not effect
> mutability.

I should add that I am experimenting with this in Jython, not CPython
which is why I said it's up to the implementation.  I immagine CPython
would add some unitialized behind-the-scenes pointer to a lock object and
lazily initialize and lock it when the object is first sychronized.  Any
subsequent asynchronizing or sychronizing would use this lock until the
object is garbage collected.

>> On the other hand, if the thing you're locking is the counter
>> attribute of slot (and ignoring for a moment where the lock is stored)
>> then what if self.counter is a list but id(self.counter) ==
>> id(globallist)?
>
> If they have the same id() they are the same object and thus the same
> associated lock. the below code will be prevented from executing at the
> same time.

Ah I'm going over all the emails I got today for my next revision and
sorry I missed where you said "attribute of the slot" the first time I
read it.  You meant, I gather, sychronizing on the slot and not the value
it stores.  Sorry to confuse things.  I do not think sychronizing on the
slot is the right thing (as I said above).

Thanks for everyones comments, please keep sending them if you have them.

-Michel