| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
called in a thread that was spawned by an import itself.
Last part to close #1665206.
|
|
|
|
|
|
| |
Was a DeprecationWarning for not supporting it since Python 2.6.
Closes issue #3652.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
#3343: Py_DisplaySourceLine should be a private function. Rename it to _Py_DisplaySourceLine.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
the stack was being unwound by two levels instead of one each time.
|
|
|
|
| |
that lacks support for the new 'line' argument.
|
|
|
|
|
|
|
| |
raised an exception properly when __file__ is not set, __name__ == '__main__',
and sys.argv[0] is a false value.
Closes issue2743.
|
| |
|
|
|
|
|
|
|
| |
warnings.showwarning() was being used. This broke pre-existing replacements for
the function since they didn't support the extra argument.
Closes issue 2705.
|
|
|
|
| |
Py3k warnings to the use of this function soon.
|
|
|
|
|
|
| |
Some other minor updates in _warnings.c:
- make a function static
- rename a shadowing local variable
|
| |
|
|
'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.
|