From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 11 Apr 1999 22:04:25 GMT
Subject: bug or feature? traceback with python -x off by one line
In-Reply-To: <3710DF00.DF5@creo.com>
References: <3710DF00.DF5@creo.com>
Message-ID: <001101be8467$43307660$2a9e2299@tim>
Content-Length: 2293
X-UID: 159                                                  

[Dale Nagata]
> I'm using Python 1.5.1 on Windows NT 4.0 Service Pack 3.

This should work the same way everywhere, 1.5.2 included.

> If I run a script the "normal" way, the exception
> traceback prints the correct source file line numbers:
>
> E:\home\dale\test\>python testx.py
> ...
>   File "E:\home\dale\test\testx.py", line 18, in ?
>     main()
> ...
>
> However, if I run the exact same script with the Python -x
> command line option to skip the first line of the script, the
> reported line numbers are consistently off by one:
>
> E:\home\dale\test>python -x testx.py
> ...
>   File "testx.py", line 17, in ?
>     try:
> ...
>
> Is this the way it's *supposed* to work?

Feeling a bit under-telepathic today, I can only confirm that the code is
functioning as written <wink>.  -x is implemented via advancing the input
file stream beyond the first line (well ...) before the parser ever sees it.
As far as the parser is concerned, the first line it sees is line number 1.

> ...
> Any ideas on the best way to resolve this?

I agree it would be nice to change.  In the meantime, I don't see a
Python-only workaround.  Under NT you don't *need* the -x trick, though
(look for NT help on "assoc" and friends; provided you have the cmd.exe
extensions enabled (the NT default), you can teach NT that .py files are to
be run by Python, much as .bat files are to be run by the command-line
interpreter; you cannot teach Win95 this, though).

> How, from within a script, can I detect that the -x option is
> in effect?

Can't; the info is long gone.

> Or do I have to go hack the interpreter source?

Start with function Py_Main in Modules\main.c.  If you get it to work, send
a patch to Guido!  I'd try replacing the "skipfirstline" fgets with a loop
that does getc until it hits a newline or EOF, and if hits a newline pushes
it back with ungetc.  This is a local change to one block of code.  Then the
first line the parser sees will be "\n", which is harmless, but will advance
the line counter.  As is, the skipfirstline block advances the stream
*beyond* the newline, and that's where you're getting in trouble; the
current code is also flawed if the first line (including trailing newline)
has more than 255 characters.

aha!-12-more-than-a-power-of-3<wink>-ly y'rs  - tim






