Guido van Rossum <guido at python.org> writes:
>> > This would be considerably improved if the error message could
>> > just point out the position in the line instead of just the line
>> > number.
>>
>> Any ideas how to do that? I guess you could obfuscate c_lnotab even
>> more...
>
> 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. :-)
That's not c_lnotab, is it? More likely co_firstlineno & co_filename.
But anyway, eek!
>> > 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!
>>
>> This is occasionally very annoying, and is probably fixable -- would
>> require pretty serious compiler hackery, though.
>
> BTW, for the special case of multi-line argument lists, it is already
> fixed.
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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4