[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Petr Viktorin added the comment: With this change, CPython no longer uses PyEval_GetFuncName/PyEval_GetFuncDesc internally. Shall we deprecate/discourage them? Shall we expose PyObject_FunctionStr publicly? -- ___ Python tracker

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

miss-islington added the comment: New changeset bf17d41826a8bb4bc1e34ba6345da98aac779e41 by Miss Islington (bot) (Jeroen Demeyer) in branch 'master': bpo-37645: add new function _PyObject_FunctionStr() (GH-14890)

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Change by Ronan Lamy : -- nosy: +Ronan.Lamy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Petr Viktorin added the comment: My bad, I didn't publish the comments. They should be there now. -- ___ Python tracker ___ ___

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Jeroen Demeyer added the comment: > I left some comments on the PR. I don't see anything. Either I'm doing something wrong or GitHub is messed up. -- ___ Python tracker ___

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Petr Viktorin added the comment: I like PR 14890 better. I like the separation of representation for error messages (where it's clearer that this is a callable) and for __str__. Also, changing the __str__ of functions would need much wider discussion than on issues/PRs. I left some

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Jeroen Demeyer added the comment: > I'm wary of "%S" used in error messages. Maybe you're misunderstanding something. The goal is not really to change error messages, only the way how they are produced. For example, we currently have >>> def f(): pass >>> f(**1) Traceback (most recent call

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Jeroen Demeyer added the comment: > I'm wary of making error messages depend on the str representation of a > function; that would prevent us from changing it later. Why wouldn't we be able to change anything? Typically, the exact string of an error message is NOT part of the API (the

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Petr Viktorin added the comment: I am not convinced. I'm wary of making error messages depend on the str representation of a function; that would prevent us from changing it later. I'm wary of "%S" used in error messages. Those are for the programmer, not the user, so they should prefer

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Change by Jeroen Demeyer : -- pull_requests: +15018 pull_request: https://github.com/python/cpython/pull/15295 ___ Python tracker ___

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Jeroen Demeyer added the comment: > Maybe repr(func) should be left unchanged, but str(func) can be enhanced? Yes, that is what I meant. -- ___ Python tracker ___

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

STINNER Victor added the comment: Maybe repr(func) should be left unchanged, but str(func) can be enhanced? -- ___ Python tracker ___

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Jeroen Demeyer added the comment: Another solution would be to change the __str__ of various function objects to a prettier output. For example, we currently have >>> def f(): pass >>> print(f) We could change this to >>> def f(): pass >>> print(f) f() and then use "%S" to display the

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14673 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14890 ___ Python tracker ___

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

Jeroen Demeyer added the comment: 4. It uses the __name__ instead of the __qualname__ -- ___ Python tracker ___ ___

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

New submission from Jeroen Demeyer : PyEval_GetFuncName is bad API because 1. It hardcodes a limited number of function classes (which doesn't even include all function classes in the core interpreter) instead of supporting duck-typing. 2. In case of a "function" object, it relies on a