Alex Martelli wrote: > I think you mean volatile or mutable rather than transient? "transient" > is not a keyword in C++, while both volatile and mutable are, with > different semantics. Anyway, C++'s 'const' is a mess both theoretical > AND practical. I'm told Ruby's "object-freezing" works better (but I > have no practical experience).
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). >>Perhaps we need a.reverse? for just-mutating-a-little reverse as well? >>;^) > > I don't see the alleged humor in this ill-defined concept. 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 instance, we can imagine lazy get methods (or why not attributes) for database access. From the users perspective, it might not matter when things are actually fetched from the database if the Python code looks like this: p = myDB.getPerson(person_id) # Perhaps fetch here. ... print p.name # Or fetch here. It's pretty common that we avoid fetching stuff from a database until we really need it, so accessing p.name, might well be the event that triggers fetching all the relevant columns in the person-table for key value person_id. That technically mutates p, but does the user of p need to be aware of that? Maybe, maybe not. I guess it depends. How are transactions and multi user issues handled? Will p.name lock a database row? 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. -- http://mail.python.org/mailman/listinfo/python-list