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

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [MAL]
> > ...
> > Since iterators can define the order in which a data structure is
> > traversed, this would also do away with the second (supposed)
> > problem.
> 
> Except we don't need iterators to do that.  If anyone thought it was
> important, they could change the existing PyDict_Next to force an ordering,
> and then everything building on that would inherit it.  So while I'm in
> favor of better iteration schemes, I'm not in favor of overselling them (on
> grounds that aren't unique to them).

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.

> >> Sorry, but immutability has nothing to do with thread safety ...
> 
> > Who said that an exception is raised ?
> 
> I did <wink>.
> 
> > The method I posted on the mutability thread allows querying
> > the current state just like you would query the availability
> > of a resource.
> 
> This?
> 
>     .mutable([flag]) -> integer
> 
>     If called without argument, returns 1/0 depending on
>     whether the object is mutable or not. When called with a
>     flag argument, sets the mutable state of the object to
>     the value indicated by flag and returns the previous flag
>     state.
> 
> If I do:
> 
>     if object.mutable():
>         object.mutate()
> 
> in a threaded world, the certain (but erratic) outcome is that sometimes it
> blows up:  there's no guarantee that another thread doesn't sneak in and
> *change* the mutability between the time object.mutable() returns 1 and
> object.mutate() acts on a bad assumption. 

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)

> Same thing for:
> 
>     if resources.num_printers_available() > 0:
>         action_that_blows_up_if_no_printers_are_available
> 
> in a threaded world.  It's possible to build a thread-safe resource
> acquisition protocol in either case, but that's really got nothing to do
> with immutability or iterators (marking a thing immutable doesn't do any
> good there unless you *also* build a protocol on top of it for communicating
> state changes, blocking until one occurs, notifications with optional
> timeouts, etc -- just doing object.mutable(1) is a threaded disaster in the
> absence of a higher-level protocol guaranteeing that this won't go changing
> the mutability state in the middle of some other thread's belief that it's
> got the thing frozen; likewise for object.mutable(0) not stepping on some
> other thread's belief that it's got permission to mutate).
> 
> .mutable(flag) is *fine* for what it does, it's simply got nothing to do
> with threads.  Thread safety could *build* on it via coordinated use of a
> threading.Sempahore (or moral equivalent), though.

Ok... :)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/