On Thu, 17 Mar 2005 23:57:52 +0100, "Martin v. Löwis" <martin at v.loewis.de> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4