DeprecationWarnings not being suppressed in 2.0.0 release

Bug #440062 reported by John A Meinel on 2009-10-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
High
John A Meinel

Bug Description

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I haven't tracked down the cause exactly, but something in the libraries
loaded for python2.6 are adding an ignore to some deprecation warnings.
This is what I get before we do our own deprecation suppression:

import warnings
f = warnings.filters[0]; f
('ignore', <bzrlib.lazy_regex.LazyRegex object at 0x025B7940>, <type
'exceptions.DeprecationWarning'>, <bzrlib.lazy_regex.LazyRegex object at
0x025B7990>, 0)

f[1]._regex_args
('sys.exc_clear', 2)

f[3]._regex_args
('threading',)

Looking at that, it seems that it is the 'threading' module itself which
is suppressing the deprecation warning. And I've confirmed that by
printing 'warnings.filter' before and after importing 'threading'.

Anyway, our current deprecation filter says "only add a filter if there
are no other filters handling deprecation warnings".

We could change this with:

=== modified file 'bzrlib/commands.py'
- --- bzrlib/commands.py 2009-06-19 09:06:56 +0000
+++ bzrlib/commands.py 2009-10-01 15:59:00 +0000
@@ -1090,7 +1090,7 @@

     # Is this a final release version? If so, we should suppress warnings
     if bzrlib.version_info[3] == 'final':
- - suppress_deprecation_warnings(override=False)
+ suppress_deprecation_warnings(override=True)
     if argv is None:
         argv = osutils.get_unicode_argv()
     else:

John
=:->

  affects bzr
  status confirmed
  milestone 2.0.1
  importance high

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrE0ewACgkQJdeBCYSNAAOROgCbBzoxKiGEYBOwz2hKyBOUsMBg
R0MAoJwKOBWAzn0LFc6c4QY2vRtAr3H1
=NSs8
-----END PGP SIGNATURE-----

Related branches

> === modified file 'bzrlib/commands.py'
> - --- bzrlib/commands.py  2009-06-19 09:06:56 +0000
> +++ bzrlib/commands.py  2009-10-01 15:59:00 +0000
> @@ -1090,7 +1090,7 @@
>
>     # Is this a final release version? If so, we should suppress warnings
>     if bzrlib.version_info[3] == 'final':
> - -        suppress_deprecation_warnings(override=False)
> +        suppress_deprecation_warnings(override=True)
>     if argv is None:
>         argv = osutils.get_unicode_argv()
>     else:

It seems reasonable to me. I don't recall why we do that - perhaps for testing.

--
Martin <http://launchpad.net/~mbp/>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
>> === modified file 'bzrlib/commands.py'
>> - --- bzrlib/commands.py 2009-06-19 09:06:56 +0000
>> +++ bzrlib/commands.py 2009-10-01 15:59:00 +0000
>> @@ -1090,7 +1090,7 @@
>>
>> # Is this a final release version? If so, we should suppress warnings
>> if bzrlib.version_info[3] == 'final':
>> - - suppress_deprecation_warnings(override=False)
>> + suppress_deprecation_warnings(override=True)
>> if argv is None:
>> argv = osutils.get_unicode_argv()
>> else:
>
> It seems reasonable to me. I don't recall why we do that - perhaps for
> testing.
>
>

So #1 we need to figure out any implications with running "python
- -Werror bzr selftest", so that make check will properly fail if we get
deprecation warnings.

#2 I think I wrote override=False because if a user custom configured
their environment to do something specific with DeprecationWarnings, I
didn't want to step on their toes. I guess I didn't expect a python
stdlib module to suppress its own deprecation warnings...

So in the balance of things, I think override=True will be better for users.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrE6QsACgkQJdeBCYSNAAM88QCfbwBFZt+dZZYvQGMnhaIg8IM6
L4IAoJjT8bOIOgADHonWmhaEpTc9/w89
=HoST
-----END PGP SIGNATURE-----

2009/10/1 John A Meinel <email address hidden>:
>>
>
> So #1 we need to figure out any implications with running "python
> - -Werror bzr selftest", so that make check will properly fail if we get
> deprecation warnings.

I've been thinking selftest should actually set up warnings filters
appropriately itself.

--
Martin <http://launchpad.net/~mbp/>

John A Meinel (jameinel) on 2009-10-13
Changed in bzr:
assignee: nobody → John A Meinel (jameinel)
status: Confirmed → Fix Committed
John A Meinel (jameinel) on 2009-10-14
Changed in bzr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers