| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
instead of looping. Smaller and clearer. Faster, too, when we're not
appending to gc.garbage: gc_list_merge() takes constant time, regardless
of the lists' sizes.
append_objects(): Moved up to live with the other list manipulation
utilities.
|
|
|
|
| |
take no arguments; cuts generated code size.
|
|
|
|
|
|
|
|
|
| |
externally unreachable objects with finalizers, and externally unreachable
objects without finalizers reachable from such objects. This allows us
to call has_finalizer() at most once per object, and so limit the pain of
nasty getattr hooks. This fixes the failing "boom 2" example Jeremy
posted (a non-printing variant of which is now part of test_gc), via never
triggering the nasty part of its __getattr__ method.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to special-case classic classes, or to worry about refcounts;
has_finalizer() deleted the current object iff the first entry in
the unreachable list has changed. I don't believe it was correct
to check for ob_refcnt == 1, either: the dealloc routine would get
called by Py_DECREF then, but there's nothing to stop the dealloc
routine from ressurecting the object, and then gc would remain at
the head of the unreachable list despite that its refcount temporarily
fell to 0 (and that would lead to an infinite loop in move_finalizers()).
I'm still worried about has_finalizer() resurrecting other objects
in the unreachable list: what's to stop them from getting collected?
|
|
|
|
|
|
| |
squashed-together conditional operators; makes it much easier to step
thru in the debugger, and to set a breakpoint on the only dangerous
path.
|
|
|
|
|
|
|
|
|
|
| |
delstr from initgc() into collect(). initgc() isn't called unless the
user explicitly imports gc, so can be used only for initialization of
user-visible module features; delstr needs to be initialized for proper
internal operation, whether or not gc is explicitly imported.
Bugfix candidate? I don't know whether the new bug was backported to
2.2 already.
|
|
|
|
|
| |
move_finalizers() moves every object from unreachable to collectable
or finalizers, unless the object is deallocated first.
|
|
|
|
|
| |
opening it in non-blocking mode. Both Guido and David Hammerton have
reported that this fixes their problems with ossaudiodev -- hooray!
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also remove a few unused variables. Built on IRIX 6.5.
|
| |
|
|
|
|
| |
can be taken, and use _SC_PAGE_SIZE if getpagesize is not available.
|
| |
|
|
|
|
| |
Will backport to 2.2.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
dump empty TODO comment
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
refactoring to get all the duplicates of this delicate code out of the
cPickle and struct modules.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
to more accurately describe what the function does.
Suggested by Thomas Wouters.
|
|
|
|
|
|
|
|
| |
for specific platforms. Use this to add plat-mac and
plat-mac/lib-scriptpackages on MacOSX. Also tested for not having adverse
effects on Linux, and I think this code isn't used on Windows anyway.
Fixes #661521.
|
|
|
|
|
|
|
| |
invalid, rather than returning a string of random garbage of the
estimated result length. Closes SF patch #703471 by Hye-Shik Chang.
Will backport to 2.2-maint (consider it done.)
|
|
|
|
| |
Factors out the common case of returning self.
|
|
|
|
| |
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!
|
| |
|
|
|
|
|
|
|
|
|
| |
it instead of the OS-specific <linux/soundcard.h> or <machine/soundcard.h>.
Mixers devices have an ioctl-only interface, no read/write -- so the
flags passed to open() don't really matter. Thus, drop the 'mode'
parameter to openmixer() (ie. second arg to newossmixerobject()) and
always open mixers with O_RDWR.
|
| |
|
|
|
|
|
|
|
| |
- The applet logic has been replaced to bundlebuilder's bootstrap script
- Due to Apple being extremely string about argv[0], we need a way to
specify the actual executable name for use with sys.executable. See
the comment embedded in the code.
|
|
|
|
|
| |
and not as a side effect of setlocale. Expose it as sys.getfilesystemencoding.
Adjust test case.
|
| |
|
|
|
|
| |
fails, as discussed in patch #683592.
|