[Patches] [ python-Patches-1692664 ] warnings.py gets filename wrong for eval/exec

SourceForge.net noreply at sourceforge.net
Mon Apr 23 08:15:09 CEST 2007


Patches item #1692664, was opened at 2007-04-01 22:23
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692664&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Library (Lib)
>Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Olsen (rhamphoryncus)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: warnings.py gets filename wrong for eval/exec

Initial Comment:
warnings.warn() gets the filename using the globals' __file__ attribute.  When using eval or exec this is often not the context in which the current line was compiled from.  The line number is correct, but will be applied to whatever file the globals are from, leading to an unrelated line being printed below the warning.

The attached patch makes it use caller.f_code.co_filename instead.  This also seems to remove the need to normalize .pyc/.pyo files, as well as not needing to use sys.argv[0] for __main__ modules.

It also cleans up warnings.warn() and adds three unit tests.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-22 23:15

Message:
Logged In: YES 
user_id=33168
Originator: NO

I'm not sure why all the code was in there to begin with it was ancient
history.  Hopefully Guido remembers.  Guido, do you see any particular
issue with this approach (ie, removing all the gyrations in warnings and
using f_code.co_filename?

There is a difference in behaviour.  If a module modifies its __file__,
the old code would pick up the modified version.  This new code will find
the real file.  I'm not sure if that's a bug or a feature though. :-) 
Similarly with __name__.

Adam, I like adding the warning_guard using a with statement.  Although I
don't think comment should be completely removed.  Could you add a comment
about why the guard is necessary (ie, the repeated calls/-R part)?

Have you tested with -R and with -u all?  ie:

  ./python -E -tt ./Lib/test/regrtest.py -R 4:3:
and
  ./python -E -tt ./Lib/test/regrtest.py -u all

(two separate runs).

In the last test case you are replacing (the old spam7), why does "sys"
become "no context"?

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-04-15 18:34

Message:
Logged In: YES 
user_id=12364
Originator: YES

I've rewritten the unit tests I added to follow the style of
walter.doerwald's changes to test_warnings.py (commited to SVN during the
same period in which I posted my patch).

The guard_warnings_registry() context manager is now in test_support.
File Added: python2.6-warningfilename4.diff

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-04-04 14:28

Message:
Logged In: YES 
user_id=12364
Originator: YES

sys._getframe(sys.maxint) produces an OverflowError on 64bit GCC.  Patch
changed to use sys._getframe(10**9) instead.
File Added: python2.6-warningfilename3.diff

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-04-03 00:00

Message:
Logged In: YES 
user_id=12364
Originator: YES

The test_stackoverflow_message test I added causes warnings.py to use
sys.__warningregistry__ rather than test_warnings.__warningregistry__. 
This circumvents this self-declared hack of deleting
test_warnings.__warningregistry__ to allow regrtest -R to run.

This version of the patch uses a more general solution to allowing
regrtest -R to run.  Probably doesn't qualify as a hack anymore...
File Added: python2.6-warningfilename2.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692664&group_id=5470


More information about the Patches mailing list