It's a rare occurrence, but sometimes my script will terminate and I get
this:
Traceback (most recent call last):
File "C:\path\to\script\script.py", line 992, in <module>
That's it. And the line number is always the last line of the file
(which in my case is a blank line). I have not seen this on Linux (where
my script can run for days or weeks on a remote server), but only on
Windows where I do most of my testing (and it typically only runs for
minutes at a time). There may be bugs in my program, but I don't see how
Python should ever print a traceback like this.
-- CPython 3.2.2 | Windows NT 6.1.7601.17640
On Fri, 03 Feb 2012 14:14:57 -0600, Andrew Berg wrote:
> It's a rare occurrence, but sometimes my script will terminate and I get
> this:
> Traceback (most recent call last):
> File "C:\path\to\script\script.py", line 992, in <module>
> That's it. And the line number is always the last line of the file
> (which in my case is a blank line).
Is it reproducible? That is, can you demonstrate a script which will *always* show this failure?
> I have not seen this on Linux (where
> my script can run for days or weeks on a remote server), but only on
> Windows where I do most of my testing (and it typically only runs for
> minutes at a time). There may be bugs in my program, but I don't see how
> Python should ever print a traceback like this.
Which version of Python, which version of Windows?
If you upgrade Python, does the problem go away?
If you perturb your script (add a few blank lines at the end, or a comment), does it go away?
Check your code in that module for open parenthesis something like below..
Most likely your code is looking for the closing parenthesis.
Start at the bottom and move up.
On Fri, 03 Feb 2012 19:15:30 -0500, inq1ltd wrote:
> Check your code in that module for open parenthesis something like
> below.. Most likely your code is looking for the closing parenthesis.
> Start at the bottom and move up.
> pink = str(self.RecordKey[2] <--missing ")"
If that were the case, the module wouldn't run at all, it would consistently raise SyntaxError before running.
On Sat, Feb 4, 2012 at 7:14 AM, Andrew Berg <bahamutzero8...@gmail.com> wrote:
> It's a rare occurrence, but sometimes my script will terminate and I get
> this:
> Traceback (most recent call last):
> File "C:\path\to\script\script.py", line 992, in <module>
Do you call on potentially-buggy external modules? I'd be curious to
see if this can happen if a module somehow sets an "error state" in
the interpreter, without actually raising an error - or,
alternatively, if a module has some kind of cleanup code that returns
failure. Unfortunately I don't have facilities for testing that, at
the moment.
On Sat, 04 Feb 2012 10:32:25 -0600, Andrew Berg wrote:
> On 2/3/2012 5:25 PM, Steven D'Aprano wrote:
>> Which version of Python, which version of Windows?
> I keep that information in my signature for every post I make to this
> list. CPython 3.2.2 | Windows NT 6.1.7601.17640
Why so you do. Did you expect that people would read it? As a rule, sigs fade into the background -- my mail client colours it grey, my news client colours it light blue, and I generally don't even notice it.
The Zen of Python applies here: explicit is better than implicit.
>> If you upgrade Python, does the problem go away?
> I use the most recent stable version. It would be hard to say if the
> problem went away since it's rare and random AFAICT.
I suggest you raise an issue on the bug tracker. If you can't reproduce the bug, it's unlikely to be fixed, but you might get lucky.
> I suggest you raise an issue on the bug tracker. If you can't reproduce > the bug, it's unlikely to be fixed, but you might get lucky.
Since I can't narrow it down to any specific circumstance or code, I'll
gather information from a build of the interpreter with debugging
enabled first.
On Sun, Feb 5, 2012 at 3:32 AM, Andrew Berg <bahamutzero8...@gmail.com> wrote:
> On 2/3/2012 9:15 PM, Chris Angelico wrote:
>> Do you call on potentially-buggy external modules?
> It imports one module that does little more than define a few simple
> functions. There's certainly no (intentional) interpreter hackery at work.
If it's safe for you to do so (copyright/licence etc), it may be worth
posting the code along with your bug report, just in case. I had some
REALLY weird issues from embedding Python that derived, ultimately,
from buggy ref management - one such case came from forgetting to
incref None; it took me a long time to track it down, because the
problem didn't actually surface until the interpreter was shutting
down.
> On Sun, Feb 5, 2012 at 3:32 AM, Andrew Berg<bahamutzero8...@gmail.com> wrote:
>> On 2/3/2012 9:15 PM, Chris Angelico wrote:
>>> Do you call on potentially-buggy external modules?
>> It imports one module that does little more than define a few simple
>> functions. There's certainly no (intentional) interpreter hackery at work.
Are you doing a conditional import, one that takes place after load
time? If you do an import within a function or class, it is executed
when the code around it executes. If you import a file with a
syntax error during execution, you could get the error message you're
getting.
> Are you doing a conditional import, one that takes place after load
> time? If you do an import within a function or class, it is executed
> when the code around it executes. If you import a file with a
> syntax error during execution, you could get the error message you're
> getting.
It does have conditional imports, but the tracebacks don't occur while
that function is running (it's executed once, and this happens well after).
