> A bit late for 2.1alpha1, but it just occurred to me that perhaps there
> should be an annotation in the documentation that indicates whether or not a
> module is thread-safe. For example, many functions in fileinput rely on a
> module global called _state. It strikes me that this module is not likely
> to be thread-safe, yet the documentation doesn't appear to mention this,
> certainly not in an obvious fashion.
>
> Anyone for adding \notthreadsafe{} and \threadsafe{} macros to the litany of
> LaTex macros in Fred's arsenal? This would make documenting these
> properties both easy and consistent across modules.
It's hard to say whether a *whole module* is threadsafe. E.g. in the
fileinput example, there's the clear implication that if you use this
in multiple threads, you should instantiate your own FileInput
instances, and then you're totally thread-safe. Clearly the semantics
of the module-global functions are thread-unsafe though.
--Guido van Rossum (home page: http://www.python.org/~guido/)
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