about sort and dictionary

[Alex Martelli]

Magnus Lycka <lycka at carmen.se> wrote:
   ...
> > I think you mean volatile or mutable rather than transient?  "transient"
   ...
> Right, volatile it is. It's really great that I can program so much
> Python now that I forget my C++! :) Thanks Alex (both for reminding me
> of forgotten C++ syntax and for making Python better).

Heh, you're welcome.  Hadn't done anything much with C++ for almost five
years, but found out (to my surprise, wouldn't have predicted it!) that
it all comes back to me effortlessly (I might put it down to working
with Matt Austern, but what we did together at Google wasn't C++...;-).
My _perl_, OTOH, *has* gone all fuzzy... go figure!  (Guess I have a
C++-shaped mind rather than a perl-shaped one, FWIW:-).


> I've run into a lot of cases where things are conceptually non-mutating,
> but in implementation, there are lots of internal state changes. For

Sure, caching and "just in time" computation are common.  That is
basically the difference between interface and implementation, and the
distinction in C++ between "logically const" and "physically const" (but
that doesn't really work right, either, for different reasons).

> While simple "warning signs" might be useful at times, I find that
> the devil is in the details, and most programming problems are too
> subtle to be described with an exclamation mark.

"Problems", yes; method names, not necessarily.  Being able to assert
that X==X' (using the X' notation to mean "X before the call") does have
expressive power; this leaves all the needed leeway to change
implementation as long as it touches "hidden" state only.  Thread safety
and atomicity are really quite different issues, just like for any class
invariant.  If there's a class invariant P(), that means that P(X')
[before the call] and P(X) [after it] both hold, but the word
"invariant" does *NOT* mean that P holds "invariably" DURING the
execution of X's methods, so class invariants cannot be used to infer
threadsafety, much less atomicity -- that would constrain the
implementation of the method WAY too much in the general case.
(_Callbacks_ from a method to generic callables passed from the outside
can be a headache -- there's no general theory as to what should hold
while an external callback executes... though I'm in the camp claiming
that invariants SHOULD hold at that time, I understand the debate).

I don't think these headaches and difficulties justify dumping the whole
field of reasoning about programs, nor the subfield of PbC.  The concept
of "immutable" is really just a tiny corner of these fields, and it's a
long way from being the hardest or most problematic one in them;-).


Alex