[Python-Dev] thread semantics for file objects
"Martin v. Löwis"
martin at v.loewis.de
Thu Mar 17 23:57:52 CET 2005
Jeremy Hylton wrote:
>>>>>Are the thread semantics for file objecst documented anywhere?
>>Literally, the answer to your question is "no".
> I'm surprised that it does not, for example, guarantee that reads and
> writes are atomic, since CPython relies on fread and fwrite which are
Where is the connection? Why would anything that CPython requires from
the C library have any effect on Python's documentation?
The only effect on Python documentation is that anybody writes it.
Nobody cares, so nobody writes documentation.
Remember, you were asking what behaviour is *documented*, not what
behaviour is guaranteed by the implementation (in a specific version
of the implementation).
> 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.
Nobody reported a bug to the Python documentation.
> <0.6 wink>. If it is not part of the specified behavior, then I
> suppose it's a quality of implementation issue. Either way it would
> be helpful if the Python documentation said something, e.g. you can
> rely on readline() being threadsafe or you can't but the current
> CPython implementation happens to be.
It would be helpful to whom? To you? I doubt this, as you will be
the one who writes the documentation :-)
> readline() seemed like an interesting case because readlines() doesn't
> have the same implementation and the behavior is different. So, as
> another example, you could ask whether readlines() has a bug or not.
Nobody knows. It depends on the Python developer who reviews the bug
report. Most likely, he considers it tricky and leaves it open for
somebody else. If his name is Martin, he will find that this is not
a bug (because it does not cause a crash, and does not contradict with
the documentation), and he will reclassify it as a wishlist item. If
his name is Tim, and if he has a good day, he will fix it, and add
a comment on floating point numbers.
More information about the Python-Dev