On 2/23/21 12:55 PM, Paul Sokolovsky wrote:
Hello,
On Tue, 23 Feb 2021 11:52:57 -0500
Ned Batchelder <n...@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 <n...@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.
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.
--Ned.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/F3DMUYIVBQQ3UJNJ3L2TXJP5HS47KJT5/
Code of Conduct: http://python.org/psf/codeofconduct/
