Hello, On Tue, 23 Feb 2021 13:09:39 -0500 Ned Batchelder <ned@nedbatchelder.com> wrote:
On 2/23/21 12:55 PM, Paul Sokolovsky wrote:
Hello,
On Tue, 23 Feb 2021 11:52:57 -0500 Ned Batchelder <ned@nedbatchelder.com> wrote:
On 2/23/21 12:56 AM, Paul Sokolovsky wrote:
Hello,
On Mon, 22 Feb 2021 17:32:23 -0500 Ned Batchelder <ned@nedbatchelder.com> wrote:
On 2/22/21 3:06 PM, Paul Sokolovsky wrote:
No, I'm proposing to stop faking lack of the last stack frame due to CPython's implementation details. See the original message for more info. I'm trying to understand what last stack frame (or lack of a last stack frame, or the faking of a lack of a last stack frame) you are talking about. Your original message shows some tracebacks, but doesn't have the code that produced them. It's hard to understand what you are referring to. Well, if you looked at that stack trace, you saw the code:
Traceback (most recent call last): File "pseudoc_tool.py", line 91, in <module> first_class_function_value(func, **pass_params) TypeError: print() got an unexpected keyword argument 'noann'
So yes, the code is:
--- first_class_function_value(func, **pass_params) ---
That's the "calling code". And the rest of the code? But's that's the whole point, that the current CPython's error reporting doesn't tell me where it is! It just tells me the function name, and go make a full-text search thru the entire sys.path to find its location, especially if there're many functions of that name.
Perhaps instead of fiddling with stack frames, we can solve this problem in a more straightforward way. The error message has a description of the function: "print()". What if we extend that description: "print() at path/to/myprog.py:173". That's what I implemented initially, saw this:
File "pseudoc_tool.py", line 91, in <module> first_class_function_value(func, **pass_params) TypeError: print() at path/to/myprog.py:173 got an unexpected keyword argument 'noann'
and wondered - why am I messing with the error *message*, if above it is a backtrace entry, which naturally shows the location information ("File "pseudoc_tool.py", line 91"). Then all things clicked into their places.
In my implementation, I didn't need to "fiddle with stack frames", I just needed to pre-populate the exception object with a first (shown last) backtrace entry for the called function, and let the usual processing append to it.
Then the existing stack traces would have the information you want, without having to debate the meaning of stack frames, and where execution happens. Without getting to the root cause, there will be only workarounds of different level of ugliness. For example, any reasonable JIT would implement proper semantics - param checking *inside* functions (just like the C code does now).
I don't think you are helping your cause by talking down to people. "any reasonable JIT" and "proper semantics" are judgemental without adding anything to the discussion.
Well, keeping repeating "we can put location info into the error message", disregarding an argument that *backtrace entries* are for location info - that should be classified as "judgemental" too then?
You wanted to know what function caused the problem. I proposed a simple solution that gave you precisely the information you wanted. But you've called it an ugly workaround for some reason.
Because I saw them both (by implementing them both), and even in the order you suggest, "location info in the message" first, felt not satisfied, spent more time to implement the alternative, and yes, that looks both more naturally and more clearly. So, please don't be judgemental to my suggestion, but consider them both, not just first which came to your mind (which is also exactly the one which came to my mind first, peace).
--Ned.
-- Best regards, Paul mailto:pmiscml@gmail.com