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

[Tim Peters]

[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).

>> 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.  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.