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).
>
> --Ned.
>
--
Best regards,
Paul mailto:pmis...@gmail.com
_______________________________________________
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/M4BIP3TEYCQNL44JGOFULFCAIZSN4CL4/
Code of Conduct: http://python.org/psf/codeofconduct/
