That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool.
I'm sorry, but that's just wrong, and I have given examples of such situations. To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the "internal" call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break.
But in ZOPE, it is definitely the case that data and program are coupled in an implicit way that makes these cases much harder to debug and avoid, because if the two methods in my example operate on different sets of data, which they probably would, or if one of them did a read before calling the external method and then afterwards a write (on an SQL database maybe), nothing would happen if I used explicit data storage! It will not happen i Zope in this case either.
No. It does happen, and it _did_ happen in my original problem. Zope doesn't even care if anything actually changes, it just considers an object changed that set self._p_changed=1.
In Zope, it's just the whole object that's tainted. You just said "different sets of data". That reasonably must mean different objects, unless you envision having huge objects with only marginally connected sets of data all stored as attributes. And then you have other problems. :-)
No. An object usually binds together different sets of data (as in the above example - it has several fields, and that is true for almost any given object). What you are saying is "don't program the ZOPE way", and it would eventually lead to the conclusion that your product classes should not have any persistent data, which is the conclusion I have come to.
That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. Eh, no they aren't.
Please don't just claim stuff. ZOPE has persistent classes. Persistent classes store data that in ordinary programs would not survive as long. In ordinary systems, you would have to find a way to store the data and retrieve it, thus having a model that isn't implicit and entangled with your code. Of course, you could do the same in ZOPE, but I addressed that above, and you could mess up ordinary code, but I think we're agreed that it is not something you should aim for (and I think I have made it clear why I do not believe it's as easy to mess up generic Python code in this way). Ole