Message159182
| Author |
sbt |
| Recipients |
Yury.Selivanov, asvetlov, benjamin.peterson, ncoghlan, pitrou, sbt |
| Date |
2012年04月24日.18:19:50 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1335291590.91.0.560722352047.issue14369@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Shouldn't test___closure__() also test what happens when the closure is replaced with None, or a tuple which is too long or too short or contains non-cell objects?
All of these things seem to be checked when you create a new function using types.FunctionType:
>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: arg 5 (closure) must be tuple
>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, ())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: g requires closure of length 2, not 0
>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, (1,2))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: arg 5 (closure) expected cell, found int
I think the setter should make similar checks. Maybe there is C code which assumes "broken" closures never happen. |
|