Robert Reynolds added the comment:
A pure python demonstration of the problem looks like this (`__file__` stores
the path to the executed module):
```python
with open(__file__) as f:
src = f.read()
with open(__file__, 'w') as f:
f.write('\n\n\n\n\n# Whoops! Wrong line!\n')
Robert Reynolds added the comment:
I second [what was said by Aigars
Mahinovs](https://bugs.python.org/issue8087#msg300990) about long-running
processes giving confusing tracebacks that make debugging very difficult. I
have a Natural Language Processing pipeline extracting features from a
Aigars Mahinovs added the comment:
As a point of update - this is a problem that can make debugging more difficult
for people running web services or other server processes that are expected to
stay alive for a long time. It is often undesirable to force a server restart
or reload every time
Robert Collins added the comment:
Oh, it may be clear to everyone already but its perhaps worth noting: there are
two ways the cache can skew.
(older source): We may have a newer file compiled and in use and the older
source in the cache.
e.g. someone calls linecache.getlines(foo.py), then
Robert Collins added the comment:
Oh, meant to add - we could just call logging.warning or something.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8087
___
Robert Collins added the comment:
Storing a marker in module objects which can be used to validate the linecache
is a good idea. timestamp isn't appropriate because of modules loaded from zips
or dynamic generation. I'd suggest we make it something opaque - we get source
code by asking the
Changes by Yuval Greenfield ubershme...@gmail.com:
--
nosy: +ubershmekel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8087
___
___
Jim Jewett jimjjew...@gmail.com added the comment:
Martin v. Löwis (loewis) wrote:
Displaying a warning whenever the code has changed on disk is
clearly unacceptable
As clarified, the request is only for when a traceback is being created (or
perhaps even only for when one is being printed).
Oleg Oshmyan chor...@inbox.lv added the comment:
I just want to note that the code might be edited not only while it is running
it in the interactive interpreter but also while it is running as a standalone
script. In this case the script naturally would not know to reload its own code
nor
Nick Coghlan ncogh...@gmail.com added the comment:
(just reviewing the idea here, not the current patch)
The problem of stale code (i.e. what was executed doesn't match what is
displayed in the traceback) is a tricky and subtle one. There are a few
different cases:
1. Source displayed does
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8087
___
___
Python-bugs-list
Diego Mascialino dmascial...@gmail.com added the comment:
On Fri, Oct 7, 2011 at 5:25 PM, Ezio Melotti rep...@bugs.python.org wrote:
Ezio Melotti ezio.melo...@gmail.com added the comment:
I'm not sure this is useful to have. If you changed your code you know that
you have to reload, so
Ezio Melotti ezio.melo...@gmail.com added the comment:
The source line showed in the traceback could not be the same line executed.
My point is that when I see an error and modify the source to fix it, then I
know that I'll have to reload. If for some reason I forget to reload, I'll get
the
Diego Mascialino dmascial...@gmail.com added the comment:
So to me, your warning will only be useful in the case where I modified the
source, forgot to reload and got the same error again with a wrong line
displayed. Also note that reloading is not so common; usually you just
restart your
Éric Araujo mer...@netwok.org added the comment:
I do not understand what the proposed feature is. I also think it should be
discussed on the python-ideas mailing list first:
http://mail.python.org/listinfo/python-ideas
--
nosy: +eric.araujo
___
Ezio Melotti ezio.melo...@gmail.com added the comment:
I'm not sure this is useful to have. If you changed your code you know that
you have to reload, so why would you want a warning that tells you that you
changed the code?
For some reason I always had the opposite problem (i.e. after a
Diego Mascialino dmascial...@gmail.com added the comment:
I worked a few hours today and I have this patch.
I tried to make a test but could not.
I know this is not a really good patch, but it's my first one and I wanted to
show my idea.
--
keywords: +patch
versions: -Python 2.7
New submission from Diego Mascialino dmascial...@gmail.com:
Example:
mod.py
def f():
a,b,c = 1,2
print b
If i do:
import mod
mod.f()
I get:
Traceback (most recent call last):
File stdin, line 1, in module
Martin v. Löwis mar...@v.loewis.de added the comment:
Displaying a warning whenever the code has changed on disk is clearly
unacceptable - it is both expensive to check (and also, how frequent would you
check?), and it would be annoying if you have long-running Python applications
so this
Diego Mascialino dmascial...@gmail.com added the comment:
Martin, I am not talking about a loop checking source file changes.
I think the check could be done only when the traceback is printed.
The function PyErr_Display() calls PyTracBack_Print() and so on until
_Py_DisplaySourceLine() is
20 matches
Mail list logo
