| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
mailing list, and in patch #722686.
|
|
|
|
|
| |
- Call this in Py_Finalize().
- Expand the Misc/NEWS text on PY_LONG_LONG.
|
| |
|
|
|
|
|
|
|
| |
the referenced object, if it has one.
Also use %p to format pointers consistently, and use <weakproxy ...>
in proxy_repr(), to match the type name.
|
|
|
|
| |
type bool. Requested in #721171.
|
|
|
|
|
| |
the thread started at
http://mail.python.org/pipermail/python-dev/2003-April/034338.html
|
|
|
|
|
| |
HTML entity names to Unicode codepoints (as integers).
codepoint2name is the reverse mapping. From SF patch #722017.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
even farther down, to just before the call to
_PyObject_DebugMallocStats(). This required the following changes:
- pystate.c, PyThreadState_GetDict(): changed not to raise an
exception or issue a fatal error when no current thread state is
available, but simply return NULL without raising an exception
(ever).
- object.c, Py_ReprEnter(): when PyThreadState_GetDict() returns NULL,
don't raise an exception but return 0. This means that when
printing a container that's recursive, printing will go on and on
and on. But that shouldn't happen in the case we care about (see
first bullet).
- Updated Misc/NEWS and Doc/api/init.tex to reflect changes to
PyThreadState_GetDict() definition.
|
|
|
|
|
| |
(This is only the tip of the iceberg; the time and datetime classes
need the same treatment.)
|
|
|
|
|
|
| |
interpreted by slicing, so negative values count from the end of the
list. This was the only place where such an interpretation was not
placed on a list index.
|
|
|
|
|
|
|
| |
A small fix for bug #545855 and Greg Chapman's
addition of op code SRE_OP_MIN_REPEAT_ONE for
eliminating recursion on simple uses of pattern '*?' on a
long string.
|
|
|
|
|
|
|
| |
- range() now works even if the arguments are longs with magnitude
larger than sys.maxint, as long as the total length of the sequence
fits. E.g., range(2**100, 2**101, 2**100) is the following list:
[1267650600228229401496703205376L]. (SF patch #707427.)
|
| |
|
|
|
|
| |
MessageBeep().
|
|
|
|
|
|
| |
recursively.
- pdb has a new command, "debug", which lets you step through
arbitrary code from the debugger's (pdb) prompt.
|
| |
|
|
|
|
| |
cases, wrote docs, added a test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
|
| |
|
| |
|
| |
|
|
|
|
|
| |
an OverflowError instead of a TypeError to be consistent
with "%c" % 256. See SF patch #710127.
|
| |
|
|
|
|
|
|
|
|
| |
instead of raising a TypeError. (From SF patch #710127)
Add tests to verify this is fixed.
Add various tests for '%c' % int.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
platforms which have dup(2). The makefile() method is built directly on top
of the socket without duplicating the file descriptor, allowing timeouts to
work properly. Includes a new test case (urllibnet) which requires the
network resource.
Closes bug 707074.
|
| |
|
| |
|
|
|
|
|
| |
"Hereby I make the script in question available under the terms and
conditions of the latest Python License."
|
|
|
|
| |
the foreground.
|
|
|
|
|
|
|
|
|
|
|
| |
a doubly-linked list, exposed by sys.getobjects(). Unfortunately, it's not
really all live objects, and it seems my fate to bump into programs where
sys.gettotalrefcount() keeps going up but where the reference leaks aren't
accounted for by anything in the list of all objects.
This patch helps a little: if COUNT_ALLOCS is also defined, from now on
type objects will also appear in this list, provided at least one object
of a type has been allocated.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pack_float, pack_double, save_float: All the routines for creating
IEEE-format packed representations of floats and doubles simply ignored
that rounding can (in rare cases) propagate out of a long string of
1 bits. At worst, the end-off carry can (by mistake) interfere with
the exponent value, and then unpacking yields a result wrong by a factor
of 2. In less severe cases, it can end up losing more low-order bits
than intended, or fail to catch overflow *caused* by rounding.
Bugfix candidate, but I already backported this to 2.2.
In 2.3, this code remains in severe need of refactoring.
|
|
|
|
|
|
|
|
|
| |
variables to store internal data. As a result, any atempts to use the
unicode system with multiple active interpreters, or successive
interpreter executions, would fail.
Now that information is stored into members of the PyInterpreterState
structure.
|
|
|
|
|
|
| |
to more accurately describe what the function does.
Suggested by Thomas Wouters.
|
| |
|
|
|
|
| |
Factors out the common case of returning self.
|
|
|
|
| |
function, if supported. (SF patch #675422, by Stuart Bishop.)
|
|
|
|
|
| |
I'm not going to have the time or energy to get this working x-platform
-- anyone who does is welcome to the code!
|
| |
|
|
|
|
|
|
|
|
| |
* Adds missing pop() methods to weakref.py
* Expands test suite to broaden coverage of objects with
a mapping interface.
Contributed by Sebastien Keim.
|
|
|
|
| |
Contributed by Brett Cannon.
|
|
|
|
|
| |
classes defined by Python code using a class statement) is now
exported from object.h as PyHeapTypeObject. (SF patch #696193.)
|
|
|
|
| |
(contributed by Michael Stone.)
|
| |
|
|
|
|
|
| |
and not as a side effect of setlocale. Expose it as sys.getfilesystemencoding.
Adjust test case.
|
|
|
|
| |
in addition to createfilehandler and creaetetimerhandler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Implement the behavior as specified in PEP 277, meaning os.listdir()
will only return unicode strings if it is _called_ with a unicode
argument.
- And then return only unicode, don't attempt to convert to ASCII.
- Don't switch on Py_FileSystemDefaultEncoding, but simply use the
default encoding if Py_FileSystemDefaultEncoding is NULL. This means
os.listdir() can now raise UnicodeDecodeError if the default encoding
can't represent the directory entry. (This seems better than silcencing
the error and fall back to a byte string.)
- Attempted to decribe the above in Doc/lib/libos.tex.
- Reworded the Misc/NEWS items to reflect the current situation.
This checkin also fixes bug #696261, which was due to os.listdir() not
using Py_FileSystemDefaultEncoding, like all file system calls are
supposed to.
|