New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
threading.Condition is not a class #57169
Comments
According to http://docs.python.org/library/threading.html#condition-objects, threading.Condition is a class. However, in fact it turns out to be function that constructs a _Condition instance. I don't know the reason for that, but it seems to me that either Condition should be a class, or the reason for it being a function should be documented so that people who I would like to inherit from Conditionknow if that is not supported, or if they can safely inherit from _Condition instead. |
Nope, it's a factory, and it's written in the doc: "threading.Condition() See Condition Objects." It has been changed in Python 3.3 (bpo-10968): threading.Condition is now a class, instead of a factory. |
On 09/13/2011 07:41 PM, STINNER Victor wrote:
Yes, but further down it still says: """
""" Best, -Nikolaus |
What do you suggest? Replace it by class threading._Condition? |
-1 on this IMHO just documenting the situation as it is would make more sense |
On 09/14/2011 04:29 AM, STINNER Victor wrote:
I don't have an optimal solution that would fit into the prescribed class threading.Condition([lock]):
Best, -Nikolaus |
I don't think this is important enough. It's now a class anyway in 3.3+. |
I recommend just closing this. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: