Hello, On Tue, 23 Feb 2021 12:31:37 +1100 Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Feb 23, 2021 at 10:10 AM Stestagg <stest...@gmail.com> wrote: > > So Python has identified that a function 'do_thing' is being called > > incorrectly, but /where/ is do_thing defined? This problem gets > > much harder if there are multiple definitions of 'do_thing' in the > > codebase, as alluded to in the original mail. > > > > Paul's suggestion is that python should add the source location of > > the function being called into the error message somewhere. > > Thank you for explaining. I'm glad I wasn't the only one confused by > the original post :) > > I think this is a nice-to-have, rather than being a serious bug to be > fixed. It's not a serious bug, it's "astonishing overlook". Astonishing, as it was there for so many years, unpatched. And of course, it's rare enough. But when it happens, you're in the maze. I spend much time communicating with Python critics (well, haters), and sometimes read quite funny criticisms like: error reporting (stacktraces) in Python is poor. I always considered that "random last resort nitpick", as error reporting in Python has always been much better than in other scripting languages (I guess by now everyone caught up). But now imagine error like that happens in some 3rd-party library. Which happened to do some first-class function/higher order programming. With functions from another 3rd-party library. Which released a new version with "slightly updated" API. All that happening in production. Someone who ever caught such (or similar) case would forever get imprint of "Python has poor error reporting". Because just imagine what you report to the maintainer of the first 3rd-party lib: "Your lib calls something wrong in file X line Y" - "Ok, let's look into that. What does it call?" - "Umm, I don't know, something called 'foo'" (or "<lambda>"). > When you get an error about a function call, it's entirely > possible that the target function is the problem, or that the wrong > function is being referenced; but you can get similar problems with > all kinds of mismatches (like "a, b, c = thing" and getting a > ValueError - maybe you'd need to check the line where 'thing' > originated). Good point. But right analogy here is: suppose error happens in "a, b, c = thing". But Python doesn't show that line in the backtrace, it stops 1 entry before it. Go figure now. 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). > If this can be done easily, great, but otherwise it might be the > domain of traceback enhancement tools rather than the core language. For Pycopy it was easy. I will look into CPython one of these weeks. > > Does execution ever (in the normal case) actually hit the 'def' line? > If so, I wouldn't be averse to having a traceback line mentioning it. > But if (as I suspect) tracing successful execution wouldn't hit that > line, then it doesn't seem right to feign execution of it. My > understanding of the def statement is that it runs ONLY when the > function is defined; when the function's called, you go straight into > the body. 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 ;-)). > > ChrisA [] -- 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/FB46HVUMI4KYBQW3URH75WV7VJBI5U3G/ Code of Conduct: http://python.org/psf/codeofconduct/
