75 lines
2.6 KiB
Plaintext
75 lines
2.6 KiB
Plaintext
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
|
|
|
|
|
|
|
|
|
|
|
|
|