incompatible change to warnings.showwarning

[exarkun]

BPO	2705
Nosy	@brettcannon, @pitrou, @benjaminp, @glyph

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/brettcannon'
closed_at = <Date 2008-05-02.02:27:04.149>
created_at = <Date 2008-04-27.19:08:54.072>
labels = ['type-bug', 'library', 'release-blocker']
title = 'incompatible change to warnings.showwarning'
updated_at = <Date 2008-05-02.02:33:51.249>
user = 'https://bugs.python.org/exarkun'

bugs.python.org fields:

activity = <Date 2008-05-02.02:33:51.249>
actor = 'brett.cannon'
assignee = 'brett.cannon'
closed = True
closed_date = <Date 2008-05-02.02:27:04.149>
closer = 'brett.cannon'
components = ['Library (Lib)']
creation = <Date 2008-04-27.19:08:54.072>
creator = 'exarkun'
dependencies = []
files = []
hgrepos = []
issue_num = 2705
keywords = []
message_count = 10.0
messages = ['65894', '65895', '65896', '65898', '65899', '65900', '65901', '66057', '66058', '66059']
nosy_count = 5.0
nosy_names = ['brett.cannon', 'exarkun', 'pitrou', 'benjamin.peterson', 'glyph']
pr_nums = []
priority = 'release blocker'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2705'
versions = ['Python 2.6']

[exarkun]

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.

[pitrou]

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?

[benjaminp]

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

[glyph]

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.

[pitrou]

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

[brettcannon]

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

[exarkun]

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.

[brettcannon]

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.

[benjaminp]

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

[brettcannon]

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.