On Thu, 17 Mar 2005 23:57:52 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Remember, you were asking what behaviour is *documented*, not what > behaviour is guaranteed by the implementation (in a specific version > of the implementation).
Martin, I think you're trying to find more finesse in my question than I ever intended. I intended to ask -- hey, what are the semantics we intend in this case? since the documentation doesn't say, we could improve them by capturing the intended semantics. > > Also, there are other operations that go to the trouble of calling > > flockfile(). What's the point if we don't provide any guarantees? > > Because nobody cares about guarantees in the documentation. Instead, > people care about observable behaviour. So if you get a crash due to a > race condition, you care, you report a bug, the Python developer agrees > its a bug, and fixes it by adding synchronization. As Tim later reported this wasn't to address a crash, but to appease a pig headed developer :-). I'm surprised by your claim that whether something is a bug depends on the person who reviews it. In practice, this may be the case, but I've always been under the impression that there was rough consensus about what constituted a bug and what a feature. I'd certainly say its a goal to strive for. It sounds like the weakest intended behavior we have is the one Tim reported: "provided the platform C stdio wasn't thread-braindead, then if you had N threads all simultaneously reading a file object containing B bytes, while nobody wrote to that file object, then the total number of bytes seen by all N threads would sum to B at the time they all saw EOF." It seems to me like a good idea to document this intended behavior somewhere. Jeremy _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
