[issue7378] unexpected truncation of traceback

2013-01-04 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

3.1 gets only security fixes. In 2.7 and 3.2+ the bug has already fixed.

--
nosy: +serhiy.storchaka
resolution:  - out of date
stage: patch review - committed/rejected
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7378
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue7378] unexpected truncation of traceback

2010-04-08 Thread Daniel Diniz

Daniel Diniz aja...@gmail.com added the comment:

Patch still applies to py3k, not applying cleanly to trunk anymore. Tests pass 
with patch on py3k.

--
nosy: +ajaksu2
priority:  - normal
stage:  - patch review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7378
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue7378] unexpected truncation of traceback

2010-04-08 Thread Ezio Melotti

Changes by Ezio Melotti ezio.melo...@gmail.com:


--
nosy: +ezio.melotti
versions: +Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7378
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue7378] unexpected truncation of traceback

2009-11-23 Thread Greg Hewgill

New submission from Greg Hewgill g...@hewgill.com:

Quite by accident, I came across a case where Python would quit
generating traceback text and skip printing the actual exception
information. Here is a sample program:

exec(compile(spam(), ., exec))

and the output in Python 3.1 (spam is undefined):

$ python3.1 test.py
Traceback (most recent call last):
  File test.py, line 1, in module
exec(compile(spam(), ., exec))
  File ., line 1, in module
$

This was bewildering until I realised that the traceback generator was
unable to read from the filename passed to compile() (my original
example was using a name other than . that wasn't intended to be a
file name, but just happened to also be a directory name). I didn't
really mind the lack of source text, but the lack of the actual
exception message was most disturbing.

This appears to be a failure mode common to both traceback.c and
traceback.py, through slightly different mechanisms. In traceback.c, if
the source filename refers to a directory, the C open() succeeds but an
error occurs when trying to read from the directory handle. In 
traceback.py, the Python open() call fails with an IOError exception, 
and the exception wasn't handled gracefully.

I have attached a patch that creates the following output instead:

$ ./python.exe test.py
Traceback (most recent call last):
  File test.py, line 1, in module
exec(compile(spam(), ., exec))
  File ., line 1, in module
[Errno 21] Is a directory: '.'
NameError: name 'spam' is not defined
$

I have tested the patch against Python 3.1, but it applies cleanly to 
the trunk (for some reason I couldn't make the trunk build, but that's 
unrelated). This patch may need some finesse for a Win32 build; I don't
have the ability to test that at the moment.

--
components: Interpreter Core, Library (Lib)
files: traceback.patch
keywords: patch
messages: 95617
nosy: ghewgill
severity: normal
status: open
title: unexpected truncation of traceback
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15384/traceback.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7378
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com