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
AssertionError in Doc/includes/mp_benchmarks.py #48699
Comments
./python Doc/includes/mp_benchmarks.py
Traceback (most recent call last):
File "Doc/includes/mp_benchmarks.py", line 235, in <module>
test()
File "Doc/includes/mp_benchmarks.py", line 203, in test
test_seqspeed(multiprocessing.Array('i', range(10), lock=False))
File
"/home/heimes/dev/python/release26-maint/Lib/multiprocessing/__init__.py",
line 254, in Array
return Array(typecode_or_type, size_or_initializer, **kwds)
File
"/home/heimes/dev/python/release26-maint/Lib/multiprocessing/sharedctypes.py",
line 87, in Array
assert hasattr(lock, 'acquire')
AssertionError The assertion error occurs when using Python 2.6 and our backports to |
The examples in 3.0 didn't work at at all because nobody did a 2to3 run |
The 3.0 doc/example issue is in bpo-3256 I plan on fixing all the doc/example issue this/next week. |
Are you able to fix the examples before 3.0.0 and 2.6.1 are released? |
Yes, I have a pending patch. I'll see if I can steal some time today On Fri, Nov 28, 2008 at 9:36 AM, Christian Heimes
|
I guess you just 2to3'ed the examples |
Jesse, please apply so we can close this issue. |
This is a documentation bug, not a library bug, right? (unless someone So: a) this seems to be a duplicate of bpo-3256, and b) it's "just" a |
This is not a doc bug - in actuality, the mp_benchmarks.py example is The doc-related bugs Christian and I spoke about have been fixed, however |
Jesse, does this affect Python 3.0? If not, then I will lower the If so, then we need to know if 1) it's really a release blocker; 2) what |
2.6.0 shipped with the assertion error. Unfortunately, I'm tapped out at |
Here is a patch nonetheless. It makes the code match the the documentation: http://docs.python.org/library/multiprocessing.html#multiprocessing.sharedctypes.Arra
I changed multiprocessing.sharedctypes.Array and multiprocessing. sharedctypes.Array |
The patch looks fine. However I propose to replace the assert statement if not hasattr(lock, 'acquire'):
raise AttributeError("'%r' has no method 'acquire'" % lock) |
+1 on Amaury's patch, however I wouldn't change the assert right now - Christian's suggestion does make sense to change globally post 3.0 Amaury, do you want to submit it? |
I don't much like the lock is True idioms much, but I don' thave a better suggestion, and it would be nice |
Indeed, it seems that multiprocessing uses assertions in many places to I can apply the patch, but what about 2.6? it's an incompatible API |
Does the language guarantee that True and False are singletons (to |
The one I know is pypy: bool(x) always return one of the two prebuilt singletons The docs explicitly mention "If lock is True...", "If lock is False...": I fear that testing the boolean value of the lock variable may have undesired effect; if |
I've changed my mind based on the API change. This should be discussed |
What about this other patch:
|
I think Amaury's patch (mp_array_2.patch) is correct. If there is no |
I agree with Martin - if no one else gets to this before me, I should be |
FYI, there was a small issue in the patch - namely the only way to get I changed the test to reflect this: self.assertRaises(AttributeError, self.Value, 'i', 5,
lock='navalue')
self.assertRaises(AttributeError,
self.Array, 'i', range(10), lock='notalock') |
Checked into trunk in r68708 - I pinged benjamin to see how we're handling |
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: