[Python-Dev] Re: Sets: elt in dict, lst.include

[Tim Peters]

[MAL]
> I'm just trying to sell iterators to bare us the pain of overloading
> the for-loop syntax just to get faster iteration over dictionaries.
>
> The idea is simple: put all the lookup, order and item building
> code into the iterator, have many of them, one for each flavour
> of values, keys, items and honeyloops, and then optimize the
> for-loop/iterator interaction to get the best performance out
> of them.
>
> There's really not much use in adding *one* special case to
> for-loops when there are a gazillion different needs to iterate
> over data structures, files, socket, ports, coffee cups, etc.

They're simply distinct issues to me.  Whether people want special syntax
for iterating over dicts is (to me) independent of how the iteration
protocol works.  Dislike of the former should probably be stabbed into
Ping's heart <wink>.

> I know. That's why you would do this:
>
> lock = []
> # we use the mutable state as lock indicator; initial state is mutable
>
> # try to acquire lock:
> while 1:
>     prevstate = lock.mutable(0)
>     if prevstate == 0:
>         # was already locked
>         continue
>     elif prevstate == 1:
>         # we acquired the lock
>         break
>
> # release lock
> lock.mutable(1)

OK, in the lingo of the field, you're using .mutable(0) as a test-and-clear
operation, and building a spin lock on top of it in "the usual" way.  In
that case the acquire code can be much simpler:

while not lock.mutable(0):
    pass

Same thing.  I agree then that has basic lock semantics (relying indirectly
on the global interpreter lock to make .mutable() calls atomic).  But
Python-level spin locks are thoroughly impractical:  a waiting thread T will
use 100% of its timeslice at 100% CPU utilization waiting for the lock, with
no chance of succeeding (the global interpreter lock blocks all other
threads while T is spinning, so no other thread *can* release the lock for
the duration -- the spinning is futile).  The performance characteristics
would be horrid.  So while "a lock", it's not a *useful* lock for threading.
You got something against Python's locks <wink>?

every-proposal-gets-hijacked-to-some-other-end-ly y'rs  - tim