less quick patch for better debugging.
Ah. Theres clearly interest in the idea. I guess its as simple as adding a field to Py_Object that would record the last namespace name used for a given object (remember any object could have many names...) (not sure about Threads btw here). This would allow for all error lookup-type error messages to be much cleaner. The impetus for the above idea being an index error on the following line: a[1] + b[2] + c[3]...currently gives an error message that doesnt say which variable the list index error occurs in or at which index it occurs at (helpful if they were all the same object on the same line). Same issues go for dicts and even any object attributes as well. PS. maybe in the interest of runtime speed, the assigning to this new field could only occur when there actually is an error.
Hunter Peress <hunterp@fastmail.fm>:
This would be considerably improved if the error message could just point out the position in the line instead of just the line number. Especially when a statement spans more than one line -- currently you can't even tell which line of a multi-line statement was the culprit! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
Any ideas how to do that? I guess you could obfuscate c_lnotab even more...
This is occasionally very annoying, and is probably fixable -- would require pretty serious compiler hackery, though. Cheers, mwh -- 3. Syntactic sugar causes cancer of the semicolon. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
I would like to point out that one solution suggested here (store the most recently used name in the object itself) cannot work -- in an expression like x[i][j], if it is the [j] part that fails, the object name displayed might be some local variable in an earlier scope that briefly refenced x[i], and that would be just plain confusing. This apart from the significant memory and CPU time overhead (which I expect whoever requested the feature doesn't care about, until they have code that runs too slow, and then they will requested a Python-to-C compiler, and be indignant when they are asked to write it themselves :-).
Probably not worth it. (I should mention that I have a possible use case for messing with the lnotab to contain line numbers in a different file than the Python source code. :-)
BTW, for the special case of multi-line argument lists, it is already fixed. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org> writes:
That's not c_lnotab, is it? More likely co_firstlineno & co_filename. But anyway, eek!
So it is. I guess the other situations that are worth fixing are long container -- list, tuple, dict -- literals. My brain is a bit too fried to think if a more general solution is feasible, but I will point out that since SET_LINENO went away, inserting superfluous calls to com_set_lineno doesn't result in superfluous bytecodes, so perhaps that could just be added to com_node or something. Although IIRC, in {k:v} v is evaluated before k, which could make life entertaining. Cheers, mwh -- ARTHUR: Don't ask me how it works or I'll start to whimper. -- The Hitch-Hikers Guide to the Galaxy, Episode 11
Michael Hudson <mwh@python.net> writes:
Although IIRC, in {k:v} v is evaluated before k, which could make life entertaining.
Another situation where (more unavoidably) execution "goes backwards": r = [i for i in somelist] Cheers, mwh -- (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman
Michael Hudson <mwh@python.net> writes:
Guido van Rossum <guido@python.org> writes:
Brain still fried, so someone else will have to tell me what's wrong with: http://python.org/sf/850789 which as sketched above calls com_set_lineno in every invocation of com_node and removes all the other calls. Cheers, mh -- Ability to type on a computer terminal is no guarantee of sanity, intelligence, or common sense. -- Gene Spafford's Axiom #2 of Usenet
Michael Hudson <mwh@python.net>:
It would need to contain a lot more information, one way or another. I don't know whether it would be worth going to heroic lengths to compress it, though. Maybe it would be better to invest the effort in making the lineno tables lazily loaded instead -- leave them in the .pyc file until they're needed. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Hunter Peress <hunterp@fastmail.fm>:
This would be considerably improved if the error message could just point out the position in the line instead of just the line number. Especially when a statement spans more than one line -- currently you can't even tell which line of a multi-line statement was the culprit! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
Any ideas how to do that? I guess you could obfuscate c_lnotab even more...
This is occasionally very annoying, and is probably fixable -- would require pretty serious compiler hackery, though. Cheers, mwh -- 3. Syntactic sugar causes cancer of the semicolon. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
I would like to point out that one solution suggested here (store the most recently used name in the object itself) cannot work -- in an expression like x[i][j], if it is the [j] part that fails, the object name displayed might be some local variable in an earlier scope that briefly refenced x[i], and that would be just plain confusing. This apart from the significant memory and CPU time overhead (which I expect whoever requested the feature doesn't care about, until they have code that runs too slow, and then they will requested a Python-to-C compiler, and be indignant when they are asked to write it themselves :-).
Probably not worth it. (I should mention that I have a possible use case for messing with the lnotab to contain line numbers in a different file than the Python source code. :-)
BTW, for the special case of multi-line argument lists, it is already fixed. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org> writes:
That's not c_lnotab, is it? More likely co_firstlineno & co_filename. But anyway, eek!
So it is. I guess the other situations that are worth fixing are long container -- list, tuple, dict -- literals. My brain is a bit too fried to think if a more general solution is feasible, but I will point out that since SET_LINENO went away, inserting superfluous calls to com_set_lineno doesn't result in superfluous bytecodes, so perhaps that could just be added to com_node or something. Although IIRC, in {k:v} v is evaluated before k, which could make life entertaining. Cheers, mwh -- ARTHUR: Don't ask me how it works or I'll start to whimper. -- The Hitch-Hikers Guide to the Galaxy, Episode 11
Michael Hudson <mwh@python.net> writes:
Although IIRC, in {k:v} v is evaluated before k, which could make life entertaining.
Another situation where (more unavoidably) execution "goes backwards": r = [i for i in somelist] Cheers, mwh -- (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman
Michael Hudson <mwh@python.net> writes:
Guido van Rossum <guido@python.org> writes:
Brain still fried, so someone else will have to tell me what's wrong with: http://python.org/sf/850789 which as sketched above calls com_set_lineno in every invocation of com_node and removes all the other calls. Cheers, mh -- Ability to type on a computer terminal is no guarantee of sanity, intelligence, or common sense. -- Gene Spafford's Axiom #2 of Usenet
Michael Hudson <mwh@python.net>:
It would need to contain a lot more information, one way or another. I don't know whether it would be worth going to heroic lengths to compress it, though. Maybe it would be better to invest the effort in making the lineno tables lazily loaded instead -- leave them in the .pyc file until they're needed. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
participants (4)
-
Greg Ewing -
Guido van Rossum -
Hunter Peress -
Michael Hudson