[issue4180] warnings.simplefilter("always") does not make warnings always show up

2017-04-18 Thread Gerrit Holl

Gerrit Holl added the comment:

I believe this fix causes this bug: http://bugs.python.org/issue29672

--
nosy: +Gerrit.Holl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2014-09-17 Thread Roundup Robot

Roundup Robot added the comment:

New changeset 8adb2c6e0803 by Antoine Pitrou in branch '3.4':
Issue #4180: The warnings registries are now reset when the filters are 
modified.
https://hg.python.org/cpython/rev/8adb2c6e0803

New changeset 4bc60eb68d3e by Antoine Pitrou in branch 'default':
Issue #4180: The warnings registries are now reset when the filters are 
modified.
https://hg.python.org/cpython/rev/4bc60eb68d3e

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2014-09-17 Thread Antoine Pitrou

Antoine Pitrou added the comment:

Ok, this is pushed to 3.x.

--
resolution:  - fixed
stage: patch review - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2014-09-04 Thread Antoine Pitrou

Antoine Pitrou added the comment:

Brett, do you want to review this?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2014-08-21 Thread Antoine Pitrou

Changes by Antoine Pitrou pit...@free.fr:


--
assignee: exarkun - 
stage: patch review - needs patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2014-08-21 Thread Antoine Pitrou

Antoine Pitrou added the comment:

Here is a patch implementing an alternate approach, with a version number added 
in the registry dicts. It also reuses Tres' test cases.

Removing 2.7 because at this point we probably don't want to add non-minimal 
changes there (outside of the ssl module, that is :-)).

--
versions:  -Python 2.7
Added file: http://bugs.python.org/file36429/warnings_issue4180.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2014-08-21 Thread Antoine Pitrou

Changes by Antoine Pitrou pit...@free.fr:


--
stage: needs patch - patch review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2014-06-05 Thread Berker Peksag

Changes by Berker Peksag berker.pek...@gmail.com:


--
nosy: +berker.peksag
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2013-01-25 Thread Brett Cannon

Changes by Brett Cannon br...@python.org:


--
nosy:  -brett.cannon

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2011-06-12 Thread Terry J. Reedy

Changes by Terry J. Reedy tjre...@udel.edu:


--
versions: +Python 3.3 -Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-12-13 Thread R. David Murray

Changes by R. David Murray rdmur...@bitdance.com:


--
type:  - behavior
versions: +Python 3.1, Python 3.2 -Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-04-30 Thread Tres Seaver

Tres Seaver tsea...@agendaless.com added the comment:

This patch tidies up the FilterWarnings tests to nomalize use of 
'self.assertEquals' (matching the rest of the module) and make the 
'test_always' assertions meaningful.

--
Added file: http://bugs.python.org/file17144/issue4180-test_janitorial.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-04-30 Thread Tres Seaver

Tres Seaver tsea...@agendaless.com added the comment:

This patch adds tests for the 'error', 'ignore', and 'always' filters being 
applied *after* the default warning has been issued, and therefore the registry 
populated.  It causes failures for the 'error' and 'always' on both the Python 
and C sides.

--
Added file: 
http://bugs.python.org/file17145/issue4180-test_filter_after_default.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-04-30 Thread Tres Seaver

Tres Seaver tsea...@agendaless.com added the comment:

This patch replaces my earlier 'py_warnings' patch.  It revamps the Python side 
to check filters before deciding not to emit the warning based on the registry. 
 The new filter_after_default tests pass on the Python side with this patch.

--
Added file: http://bugs.python.org/file17146/issue4180-py_warnings2.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-04-29 Thread Tres Seaver

Tres Seaver tsea...@agendaless.com added the comment:

The attached patch fixes the OP's use case on the Python side by re-ordering 
the tests, such that always prevents the short-circuit from firing::

 $ ./python 
 Python 2.6.5+ (release26-maint, Apr 29 2010, 21:24:12) 
 [GCC 4.3.3] on linux2
 Type help, copyright, credits or license for more information.
  import warnings as o_warnings
  import sys
  sys.modules['_warnings'] = 0
  del sys.modules['warnings']
  import warnings as py_warnings
  def f():
 ... py_warnings.warn('foo')
 ... 
  f()
 __main__:2: UserWarning: foo
  f()
  py_warnings.simplefilter('always')
  f()
 __main__:2: UserWarning: foo
  f()
 __main__:2: UserWarning: foo

--
components: +Library (Lib) -Interpreter Core
nosy: +tseaver
type: behavior - 
Added file: http://bugs.python.org/file17141/issue4180-py_warnings.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-03-08 Thread Antoine Pitrou

Antoine Pitrou pit...@free.fr added the comment:

It sounds like it would be cleaner to apply Brett's idea in msg75122, rather 
than have the user override (and alternate implementations implement) another 
obscure hook. We have enough hooks that nobody knows about, IMHO.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-03-06 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

+1 for Benjamin's patch, having just been bitten by this exact problem.

I'm trying to do unit testing, checking both that a piece of code produces a 
DeprecationWarning and that it gives the correct result, with something like:

with warnings.catch_warnings():
warnings.filterwarnings(ignore, category=DeprecationWarning)
self.assertEqual(my_func(my_args), expected_result)

with warnings.catch_warnings():
warnings.filterwarnings(error, category=DeprecationWarning)
self.assertRaises(DeprecationWarning, my_func, *my_args)

The first call still registers the warning, even though it's ignored, so the 
second assertRaises fails.  Benjamin's patch would seem to provide a way to fix 
this.

Perhaps I'm missing an obvious better way to do this.

N.B. The above is a too simple version of the real problem: it actually works 
as intended, for fragile reasons:  the ignored warning is registered on 
__name__, while the alwaysd warning ends up being registered on 
unittest.case, so there's no conflict.

--
nosy: +mark.dickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2010-03-06 Thread Florent Xicluna

Changes by Florent Xicluna florent.xicl...@gmail.com:


--
components: +Interpreter Core
nosy: +flox
stage:  - patch review
versions: +Python 2.7 -Python 2.4, Python 2.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2009-06-12 Thread Jean-Paul Calderone

Jean-Paul Calderone exar...@divmod.com added the comment:

So how about it?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2009-06-12 Thread Brett Cannon

Brett Cannon br...@python.org added the comment:

I am still on sabbatical so no code review from me.

But from the standpoint of making warn_explicit be overloadable, I'm on 
the fence. I don't mind it happening, but it will be just one more thing 
we have to support. Since it's Benjamin's code he can make the call to add 
the feature.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Jean-Paul Calderone

New submission from Jean-Paul Calderone [EMAIL PROTECTED]:

If a warning is emitted then a filter with the always rule is added
then the is emitted again, it will not be shown the second time:

  [EMAIL PROTECTED]:~$ 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)
  ... 
   f()
  /home/exarkun/.pythonstartup.py:2: UserWarning: foo
   warnings.simplefilter(always)
   f()
   

The always filter is documented as always print matching warnings
which is contrary to this behavior.  Also, the string always strongly
implies that it will be shown the second time.

--
messages: 75113
nosy: exarkun
severity: normal
status: open
title: warnings.simplefilter(always) does not make warnings always show up
versions: Python 2.4, Python 2.5, Python 2.6

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Benjamin Peterson

Benjamin Peterson [EMAIL PROTECTED] added the comment:

If you didn't raise the warning before using the simple filter, this
would have worked. The undesired behavior is because of
__warningsregistry__. It is set the first time the warning is emitted.
When the second warning comes through, the filter isn't even looked at.
I think the best way to fix this is to invalidate __warningsregistry__
when a filter is used. It would probably be best to store warnings data
in a global then instead of on the module, so it is easy to invalidate.

--
nosy: +benjamin.peterson, brett.cannon
priority:  - high

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Brett Cannon

Brett Cannon [EMAIL PROTECTED] added the comment:

Obviously the big problem with that change, Benjamin, is you will be
changing the semantics. And that is a tough thing to change when it
involves the warning machinery itself so emitting a warning about a
warning might get messy.

--
type:  - behavior

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Benjamin Peterson

Benjamin Peterson [EMAIL PROTECTED] added the comment:

Oh, do we not consider __warningsregistry__ an implementation detail?

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Brett Cannon

Brett Cannon [EMAIL PROTECTED] added the comment:

On Wed, Oct 22, 2008 at 3:39 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:

 Benjamin Peterson [EMAIL PROTECTED] added the comment:

 Oh, do we not consider __warningsregistry__ an implementation detail?


I guess you could view it that way. I just know I find it extremely
annoying for testing for the exact reasons JP mentions; it's
unexpected if you don't know about it.

If we made __warningsregistry__  about just recording what warnings
have been raised and not include filter information (which I what I
think you are suggesting) then it would still server its purpose,
albeit for probably a small performance penalty. Probably whomever
came up with it over-optimized and just didn't realize that it might
play havoc with testing.

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Benjamin Peterson

Benjamin Peterson [EMAIL PROTECTED] added the comment:

A simple solution would be to allow warn_explicit to be overridden. Then
a custom warn_explicit function could simply ignore the registry argument.

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Brett Cannon

Brett Cannon [EMAIL PROTECTED] added the comment:

On Wed, Oct 22, 2008 at 4:11 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:

 Benjamin Peterson [EMAIL PROTECTED] added the comment:

 A simple solution would be to allow warn_explicit to be overridden. Then
 a custom warn_explicit function could simply ignore the registry argument.

You say simple from a comprehension standpoint, I say pain in
terms of implementing it in C (although most of the hard stuff I
already have worked out for showwarning).

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4180] warnings.simplefilter(always) does not make warnings always show up

2008-10-22 Thread Benjamin Peterson

Benjamin Peterson [EMAIL PROTECTED] added the comment:

Don't worry, Brett; you made it really easy. :) Here's a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file11866/warn_explicit_replace.patch

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4180
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com