In Python 2.5 and earlier, passing stacklevel=0 to warnings.warn
resulted in a warning shown which pointed to warnings.py.  In Python
2.6, passing a stacklevel of 0 results in the warning shown pointing to
the file containing the call to warnings.warn.  To illustrate:

  exarkun@charm:~$ python
  Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
  [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import warnings
  >>> def f():
  ...     warnings.warn("foo", stacklevel=0)
  ... 
  >>> f()
  /usr/lib/python2.5/warnings.py:41: UserWarning: foo
    lineno = caller.f_lineno
  >>> 

as compared to

  exarkun@charm:~$ ~/Projects/python/branches/release26-maint/python 
  Python 2.6+ (trunk:66997, Oct 22 2008, 14:43:32) 
  [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import warnings
  >>> def f():
  ...     warnings.warn("foo", stacklevel=0)
  ... 
  >>> f()
  __main__:2: UserWarning: foo
  >>> 

This breaks code which assumes that stacklevel=0 will result in a
different file than stacklevel=1.

The reason for this is that the C implementation of warnings doesn't
show up on the frame stack. (The pure Python implementation of warnings
in 2.6 works like in 2.5.) The only solution for this one might be using
the Python implementation. (I'd also be interested to know why a
stacklevel of 0 is being used.)

Perhaps the C implementation should interpret the stacklevel parameter
differently so that it is compatible with the Python implementation. 
The stacklevel value is, after all, a very important part of the
interface of warnings.warn, as it is the only way to direct the warning
at a piece of code.

If the C implementation doesn't add a frame to the stack, then maybe it
should special case stacklevel=0 (eg, pointing somewhere arbitrary, not
real, and obviously so).  It seems that it already accounts for this
fact for other stacklevel values, as it doesn't exhibit the obvious
off-by-one error one might expect.

Or, close this ticket as won't-fix, if there is no intention of ever
fixing it.