Nick Coghlan added the comment: 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)? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2786> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
