In Python 2.5 and earlier, the `showwarning´ function in the `warnings´
module has this signature:

  def showwarning(message, category, filename, lineno, file=None):

In trunk (and presumably what will become Python 2.6), this has become:

  def showwarning(message, category, filename, lineno, file=None,
line=None):

`showwarning´ is documented as a hook which libraries or applications
may override in order to control how warnings are reported.  The
addition of a new parameter to the function and the change to related
code to call it with an argument for that new parameter means that
libraries and applications which replaced it will not work without
modification on Python 2.6.  Instead, a `TypeError´ will be raised when
a warning is emitted.

I suggest restoring the previous signature for `showwarning´ and adding
a new (perhaps preferred) API for showing a warning with the extra
information available.  It may also make sense to emit a deprecation
warning when an overridden old-style `showwarning´ is found.

Well, all you have to do is to change the hook's signature to the new
one and, since the last parameter is optional, it should not cause any
backwards compatibility problems. That is, the new hook should work fine
on Python < 2.6 as well. Am I missing something?

We should have an entry under "Porting to 2.6" in whatsnew.

pitrou: You're missing a few steps.  If you are maintaining project X,
which depends on library Y, that adds a showwarning hook for some
reason, you need to:

 * check out a development version of library Y, which you do not
normally maintain
 * change the hook's signature to the new one
 * submit a patch to library Y
 * make a local fork of library Y so that you can verify the rest of
your code under 2.6
 * send out an email to your mailing list explaining that they cannot
run with python 2.6 without this patch (linking to the patch in library Y)
 * write a FAQ entry because 200 people show up asking why it does not
work on python 2.6
 * if library Y's development is slow, do a new release of project X
which includes monkeypatching to allow running project X on 2.6

These steps may be unavoidable if library Y has been unmaintained for a
long enough time, but it would be nice to be able to avoid this with a
single new Python release.

Is it a theoretical case or are you thinking about a specific library Y? 

Also, seeing some things break when a new Python version is released is
not new as you certainly know : see
http://twistedmatrix.com/trac/ticket/1867

I have emailed python-dev to try to decide how to handle this.

By the way, I just noticed that Lib/idlelib/PyShell.py includes an
override of `showwarning´ which is defined with the old signature.

I ran idle from trunk and verified that is indeed breaks warning reporting.

Fixed in r62626. I left in the optional arguments but they are just not 
called anymore by the 'warnings' machinery. I might add a 
PendingDeprecationWarning so that people start to add the argument, 
though, for future use.

Why don't you add a Py3k warning and keep it in Py3k?

On Thu, May 1, 2008 at 7:29 PM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
>  Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
>  Why don't you add a Py3k warning and keep it in Py3k?

Just asked python-dev if they are okay with that. 2.6 could get a
PendingDeprecationWarning and 3.0 could get a DeprecationWarning. But
I don't want to do an API change between the two that breaks code like
that.