Author ncoghlan
Recipients Arfrever, belopolsky, ezio.melotti, gvanrossum, ilblackdragon, martin.panter, ncoghlan, o11c, pitrou, rbcollins, smurfix, xonatius
Date 2015-08-26.10:17:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hmm, I'd made the same mistake Martin did - I was looking at the tracebacks moreso than at the exception message itself. Looking at the argument unpacking exception message in the context of the test case above, that also uses __code__.co_name rather than the runtime function name:

>>> g(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: g() takes 0 positional arguments but 1 was given

In this case though, I think that's arguably a problem, as we probably want error messages (unlike tracebacks) to include the "intended for human consumption" name, but they currently don't, they expose the name of the wrapper function if it's actually constraining its arguments rather than passing them through for subsequent validation:

>>> def make_wrapper(f):
...     @functools.wraps(f)
...     def wrapper():
...         return f()
...     return wrapper
>>> @make_wrapper
... def g():
...     return f()
>>> g(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: wrapper() takes 0 positional arguments but 1 was given

That makes me more inclined towards a solution like Daniil's patch, but the growing signature of PyEval_Code* still bothers me. Perhaps we could collect the various runtime state arguments up into a "PyEvalScope" struct and make the new API PyEval_EvalCodeInScope(PyObject *code, PyObject *scope)?
Date User Action Args
2015-08-26 10:17:34ncoghlansetrecipients: + ncoghlan, gvanrossum, belopolsky, pitrou, rbcollins, ezio.melotti, smurfix, Arfrever, martin.panter, o11c, ilblackdragon, xonatius
2015-08-26 10:17:34ncoghlansetmessageid: <>
2015-08-26 10:17:34ncoghlanlinkissue2786 messages
2015-08-26 10:17:34ncoghlancreate