Search

Home

Sort by

Searched refs:unreachable (Results 1 - 3 of 3) sorted by relevance

/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.10/Modules/
H A D	gcmodule.c	197 indirectly) from outside the generation into an "unreachable" set. 199 again. Objects that are found to be unreachable have gc_refs set to 434 /* Move the unreachable objects from young to unreachable. After this, 436 * unreachable have gc_refs = GC_TENTATIVELY_UNREACHABLE. All tracked 437 * gc objects not in young or unreachable still have gc_refs = GC_REACHABLE. 439 * from outside the original young; and all objects in unreachable are 443 move_unreachable(PyGC_Head young, PyGC_Head unreachable) argument 450 * from the original young "to the left" of us are in unreachable now, 481 /* This may be unreachable 537 move_finalizers(PyGC_Head unreachable, PyGC_Head finalizers) argument 601 handle_weakrefs(PyGC_Head unreachable, PyGC_Head old) argument 879 PyGC_Head unreachable; /* non-problematic unreachable trash */ local [all...]
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Modules/
H A D	gcmodule.c	157 indirectly) from outside the generation into an "unreachable" set. 159 again. Objects that are found to be unreachable have gc_refs set to 394 /* Move the unreachable objects from young to unreachable. After this, 396 * unreachable have gc_refs = GC_TENTATIVELY_UNREACHABLE. All tracked 397 * gc objects not in young or unreachable still have gc_refs = GC_REACHABLE. 399 * from outside the original young; and all objects in unreachable are 403 move_unreachable(PyGC_Head young, PyGC_Head unreachable) argument 410 * from the original young "to the left" of us are in unreachable now, 444 /* This may be unreachable 486 move_finalizers(PyGC_Head unreachable, PyGC_Head finalizers) argument 550 handle_weakrefs(PyGC_Head unreachable, PyGC_Head old) argument 828 PyGC_Head unreachable; /* non-problematic unreachable trash */ local [all...]
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Lib/pydoc_data/
H A D	topics.py	54 'objects': u'\nObjects, values and types\n************************\n\nObjects* are Python\'s abstraction for data. All data in a Python\nprogram is represented by objects or by relations between objects. (In\na sense, and in conformance to Von Neumann\'s model of a "stored\nprogram computer," code is also represented by objects.)\n\nEvery object has an identity, a type and a value. An object\'s\nidentity never changes once it has been created; you may think of it\nas the object\'s address in memory. The \'``is``\' operator compares the\nidentity of two objects; the ``id()`` function returns an integer\nrepresenting its identity (currently implemented as its address). An\nobject\'s type is also unchangeable. [1] An object\'s type determines\nthe operations that the object supports (e.g., "does it have a\nlength?") and also defines the possible values for objects of that\ntype. The ``type()`` function returns an object\'s type (which is an\nobject itself). The value of some objects can change. Objects\nwhose value can change are said to be mutable; objects whose value\nis unchangeable once they are created are called immutable. (The\nvalue of an immutable container object that contains a reference to a\nmutable object can change when the latter\'s value is changed; however\nthe container is still considered immutable, because the collection of\nobjects it contains cannot be changed. So, immutability is not\nstrictly the same as having an unchangeable value, it is more subtle.)\nAn object\'s mutability is determined by its type; for instance,\nnumbers, strings and tuples are immutable, while dictionaries and\nlists are mutable.\n\nObjects are never explicitly destroyed; however, when they become\nunreachable they may be garbage-collected. An implementation is\nallowed to postpone garbage collection or omit it altogether --- it is\na matter of implementation quality how garbage collection is\nimplemented, as long as no objects are collected that are still\nreachable.\n\nCPython implementation detail: CPython currently uses a reference-\ncounting scheme with (optional) delayed detection of cyclically linked\ngarbage, which collects most objects as soon as they become\nunreachable, but is not guaranteed to collect garbage containing\ncircular references. See the documentation of the ``gc`` module for\ninformation on controlling the collection of cyclic garbage. Other\nimplementations act differently and CPython may change. Do not depend\non immediate finalization of objects when they become unreachable (ex:\nalways close files).\n\nNote that the use of the implementation\'s tracing or debugging\nfacilities may keep objects alive that would normally be collectable.\nAlso note that catching an exception with a \'``try``...``except``\'\nstatement may keep objects alive.\n\nSome objects contain references to "external" resources such as open\nfiles or windows. It is understood that these resources are freed\nwhen the object is garbage-collected, but since garbage collection is\nnot guaranteed to happen, such objects also provide an explicit way to\nrelease the external resource, usually a ``close()`` method. Programs\nare strongly recommended to explicitly close such objects. The\n\'``try``...``finally``\' statement provides a convenient way to do\nthis.\n\nSome objects contain references to other objects; these are called\ncontainers. Examples of containers are tuples, lists and\ndictionaries. The references are part of a container\'s value. In\nmost cases, when we talk about the value of a container, we imply the\nvalues, not the identities of the contained objects; however, when we\ntalk about the mutability of a container, only the identities of the\nimmediately contained objects are implied. So, if an immutable\ncontainer (like a tuple) contains a reference to a mutable object, its\nvalue changes if that mutable object is changed.\n\nTypes affect almost all aspects of object behavior. Even the\nimportance of object identity is affected in some sense: for immutable\ntypes, operations that compute new values may actually return a\nreference to any existing object with the same type and value, while\nfor mutable objects this is not allowed. E.g., after ``a = 1; b =\n1``, ``a`` and ``b`` may or may not refer to the same object with the\nvalue one, depending on the implementation, but after ``c = []; d =\n[]``, ``c`` and ``d`` are guaranteed to refer to two different,\nunique, newly created empty lists. (Note that ``c = d = []`` assigns\nthe same object to both ``c`` and ``d``.)\n',

Completed in 29 milliseconds