restricting itself to just functions and methods (which allows
built-in functions to be used, etc.).
Closes issue #10271. Thanks to lekma for the bug report.
'once_registry'. This is bad as the warnings module had variables named
'defaultaction' and 'onceregistry' which are what people should be looking at
(technically those variables shouldn't be mucked with as they are undocumented,
but we all know better than to believe that isn't happening). So the variables
from _warnings have been renamed to come off as private and to avoid confusion
over what variable should be used.
Closes issue #9766. Thanks to Antoine Pitrou for the discovery.
setup_context() replaces .pyc or .pyo filename suffix by .py, but it
didn't work if the filename contains a non-ascii character because the
function used the wrong unit for the length (number of characters
instead of the number of bytes).
With this patch, it uses unicode filenames instead of bytes filenames,
to fix the bug and to be fully unicode compliant.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77402 | brett.cannon | 2010-01-09 20:56:19 -0600 (Sat, 09 Jan 2010) | 12 lines
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.
........
r77505 | brett.cannon | 2010-01-14 14:00:28 -0600 (Thu, 14 Jan 2010) | 7 lines
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.
........
r77510 | brett.cannon | 2010-01-14 19:31:45 -0600 (Thu, 14 Jan 2010) | 1 line
Remove C++/C99-style comments.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r82059 | victor.stinner | 2010-06-18 01:08:50 +0200 (ven., 18 juin 2010) | 5 lines
Issue #6543: Write the traceback in the terminal encoding instead of utf-8.
Fix the encoding of the modules filename.
Reindent also traceback.h, just because I hate tabs :-)
........
r82061 | victor.stinner | 2010-06-18 01:17:37 +0200 (ven., 18 juin 2010) | 2 lines
Issue #6543: Mention the author of the patch, Amaury Forgeot d'Arc
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r81364 | victor.stinner | 2010-05-19 22:40:50 +0200 (mer., 19 mai 2010) | 3 lines
Issue #8766: Initialize _warnings module before importing the first module.
Fix a crash if an empty directory called "encodings" exists in sys.path.
........
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.
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.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
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.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
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.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r70965 | brett.cannon | 2009-04-01 11:03:59 -0700 (Wed, 01 Apr 2009) | 5 lines
_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.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r66748 | christian.heimes | 2008-10-02 21:47:50 +0200 (Thu, 02 Oct 2008) | 1 line
Fixed a couple more C99 comments and one occurence of inline.
........
+ another // comment in bytesobject
svn+ssh://pythondev@svn.python.org/python/trunk
........
r66748 | christian.heimes | 2008-10-02 21:47:50 +0200 (Thu, 02 Oct 2008) | 1 line
Fixed a couple more C99 comments and one occurence of inline.
........
Antoine Pitrou
Benjamin Peterson
Florent Xicluna
Victor Stinner
Martin v. Löwis
Brett Cannon
Ezio Melotti
Georg Brandl
Brett Cannon
Alexandre Vassalotti
Hirokazu Yamamoto
Jeffrey Yasskin
Christian Heimes