On Tue, Feb 23, 2021 at 5:33 PM Paul Sokolovsky <pmis...@gmail.com> wrote:
> Because that's the right analogy of what happens with a function - in
> the function "prolog", there's a series of assignments:
> "formal_paramX = actual_argX". Conceptually, those *are* in the
> function context (or you would not be able to reference function's
> formal params).

But they aren't actual lines of code. Your analogy breaks down because
you're trying to put a line into a backtrace for a mythical and
conceptual action that happens as part of the function call.

That's why I dispute that this is an "astonishing oversight". It would
be nice to have the extra information, but given that Python and
Python programmers have survived for thirty years without it, I don't
think it's nearly as serious as you're implying.

> For another analogy, you can look at how native functions are defined
> and where they check params, and from where exceptions originate there
> (by obvious reasons, Python backtraces don't show C source code
> function/linenos ;-)).

Yes, or you could look at CPython byte code and how it does a bunch of
stack operations, but some of them don't actually happen. Looking at
the implementation, especially in a completely different language,
doesn't really help here :)

The way I see it, this is perfect as an "additional information"
field. For instance, when I compile certain buggy C programs, gcc
tells me things like this:

demo.c: In function ‘main’:
demo.c:4:9: warning: passing argument 1 of ‘printf’ makes pointer from
integer without a cast [-Wint-conversion]
  printf(12345);
         ^~~~~
In file included from demo.c:1:
/usr/include/stdio.h:332:43: note: expected ‘const char * restrict’
but argument is of type ‘int’
 extern int printf (const char *__restrict __format, ...);
                    ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~

It starts by reporting the error, and then says "note: the thing
you're calling came from over here". It's separate from the error
itself, but provides extremely useful information.

Python doesn't currently have a standardized way to report this, but
IMO that would be a far better way than synthesizing a fake backtrace
entry.

Taking your original example, it might look something like this:

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'

Note: The function is defined here:
    File "whatever.py", line 123, in <module>
      def print(thingy, thongy, whop):

ChrisA
_______________________________________________
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/5Z4JLH76N6OL4DGF4CBD3IY7GQQOL2VR/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to