Commit Graph

26 Commits

Author SHA1 Message Date
Brett Cannon 1994969c15 When DeprecationWarning was silenced by default, it also silenced any use of -Q
by default as well. This change fixes that by treating -Q like -3 when it comes
to DeprecationWarning; using it causes the silencing to not occur.

Fixes issue #7319.
2010-04-25 22:33:36 +00:00
Brett Cannon 0bc77474aa Remove C++/C99-style comments. 2010-01-15 01:31:45 +00:00
Brett Cannon 3ffa43db48 The silencing of DeprecationWarning was not taking -3 into consideration. Since
Py3K warnings are DeprecationWarning by default this was causing -3 to
essentially be a no-op. Now DeprecationWarning is only silenced if -3 is not
used.

Closes issue #7700. Thanks Ezio Melotti and Florent Xicluna for patch help.
2010-01-14 20:00:28 +00:00
Brett Cannon 6fdd3dcb6a DeprecationWarning is now silent by default.
This was originally suggested by Guido, discussed on the stdlib-sig mailing
list, and given the OK by Guido directly to me. What this change essentially
means is that Python has taken a policy of silencing warnings that are only
of interest to developers by default. This should prevent users from seeing
warnings which are triggered by an application being run against a new
interpreter before the app developer has a chance to update their code.

Closes issue #7319. Thanks to Antoine Pitrou, Ezio Melotti, and Brian Curtin
for helping with the issue.
2010-01-10 02:56:19 +00:00
Hirokazu Yamamoto e78e5d2e51 Issue #6415: Fixed warnings.warn sagfault on bad formatted string. 2009-07-17 06:20:46 +00:00
Jeffrey Yasskin f7f858d141 Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.

The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field.  So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
2009-05-08 22:23:21 +00:00
Brett Cannon 15ba4dae5a _warnings was importing itself to get an attribute. That's bad if warnings gets
called in a thread that was spawned by an import itself.

Last part to close #1665206.
2009-04-01 18:03:59 +00:00
Brett Cannon 6c4cff0f32 Require implementations for warnings.showwarning() support the 'line' argument.
Was a DeprecationWarning for not supporting it since Python 2.6.

Closes issue #3652.
2009-03-11 04:51:06 +00:00
Christian Heimes 32a66a0410 Fixed a couple more C99 comments and one occurence of inline. 2008-10-02 19:47:50 +00:00
Brett Cannon 1eaf0742d8 Move test.test_support.catch_warning() to the warnings module, rename it
catch_warnings(), and clean up the API.

While expanding the test suite, a bug was found where a warning about the
'line' argument to showwarning() was not letting functions with '*args' go
without a warning.

Closes issue 3602.
Code review by Benjamin Peterson.
2008-09-02 01:25:16 +00:00
Amaury Forgeot d'Arc 2252d11c08 #3342: In tracebacks, printed source lines were not indented since r62555.
#3343: Py_DisplaySourceLine should be a private function. Rename it to _Py_DisplaySourceLine.
2008-07-11 21:45:06 +00:00
Brett Cannon dea1b5653f warnings.warn_explicit() did not have the proper TypeErrors in place to prevent
bus errors or SystemError being raised. As a side effect of fixing this, a bad
DECREF that could be triggered when 'message' and 'category' were both None was
fixed.

Closes issue 3211. Thanks JP Calderone for the bug report.
2008-06-27 00:31:13 +00:00
Gregory P. Smith dd96db63f6 This reverts r63675 based on the discussion in this thread:
http://mail.python.org/pipermail/python-dev/2008-June/079988.html

Python 2.6 should stick with PyString_* in its codebase.  The PyBytes_* names
in the spirit of 3.0 are available via a #define only.  See the email thread.
2008-06-09 04:58:54 +00:00
Benjamin Peterson dacde0d6ae turn PyErr_WarnPy3k into a macro 2008-05-26 17:43:53 +00:00
Christian Heimes 593daf545b Renamed PyString to PyBytes 2008-05-26 12:51:38 +00:00
Georg Brandl 9c5b51541c Fix a refleak in the _warnings module. 2008-05-13 21:32:03 +00:00
Benjamin Peterson d295032910 Fix logic error in Python/_warnings.c and add a test to verify 2008-05-06 22:18:11 +00:00
Brett Cannon e3dcb01bfc Fix a bug in the handling of the stacklevel argument in warnings.warn() where
the stack was being unwound by two levels instead of one each time.
2008-05-06 04:37:31 +00:00
Brett Cannon 8a232cc385 Add a DeprecationWarning for when warnings.showwarning() is set to a function
that lacks support for the new 'line' argument.
2008-05-05 05:32:07 +00:00
Brett Cannon 64a4bbeb25 Fix the C implementation of 'warnings' to infer the filename of the module that
raised an exception properly when __file__ is not set, __name__ == '__main__',
and sys.argv[0] is a false value.

Closes issue2743.
2008-05-03 03:19:39 +00:00
Brett Cannon ab9cc1b7ad Fix some indentation errors. 2008-05-03 01:02:41 +00:00
Brett Cannon b457ddaff2 Fix a backwards-compatibility mistake where a new optional argument for
warnings.showwarning() was being used. This broke pre-existing replacements for
the function since they didn't support the extra argument.

Closes issue 2705.
2008-05-02 02:25:09 +00:00
Benjamin Peterson a692c4df63 Added PyErr_WarnPy3k function. (issue 2671) I will be converting current Py3k warnings to the use of this function soon. 2008-04-27 02:28:02 +00:00
Amaury Forgeot d'Arc f9e7ebe165 Correct a refleak found by "regrtest.py -R:: test_structmembers"
Some other minor updates in _warnings.c:
- make a function static
- rename a shadowing local variable
2008-04-14 20:07:48 +00:00
Christian Heimes 6715352848 Use PyString_InternFromString instead of PyString_FromString for static vars 2008-04-13 09:33:24 +00:00
Brett Cannon e974689038 Re-implement the 'warnings' module in C. This allows for usage of the
'warnings' code in places where it was previously not possible (e.g., the
parser). It could also potentially lead to a speed-up in interpreter start-up
if the C version of the code (_warnings) is imported over the use of the
Python version in key places.

Closes issue #1631171.
2008-04-12 23:44:07 +00:00