Searched refs:comparison (Results 1 - 14 of 14) sorted by relevance

/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Lib/lib2to3/fixes/
H A Dfix_has_key.py88 if arg.type in (syms.comparison, syms.not_test, syms.and_test,
100 new = pytree.Node(syms.comparison, (arg, n_op, before))
104 if node.parent.type in (syms.comparison, syms.expr, syms.xor_expr,
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.10/Include/
H A Dgraminit.h55 #define comparison 308 macro
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Include/
H A Dgraminit.h55 #define comparison 308 macro
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Lib/
H A Dsymbol.py65 comparison = 308 variable
H A Ddecimal.py777 'comparison involving sNaN',
781 'comparison involving sNaN',
785 'comparison involving NaN',
789 'comparison involving NaN',
849 # subject of what should happen for a comparison involving a NaN.
3430 comparison = self._cmp(other)
3431 if comparison == 0:
3434 if comparison == -1:
3436 else: # comparison == 1
3991 place of that operand for the comparison instea
[all...]
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.10/Lib/pydoc_data/
H A Dtopics.py16 'booleans': u'\nBoolean operations\n******************\n\n or_test ::= and_test | or_test "or" and_test\n and_test ::= not_test | and_test "and" not_test\n not_test ::= comparison | "not" not_test\n\nIn the context of Boolean operations, and also when expressions are\nused by control flow statements, the following values are interpreted\nas false: "False", "None", numeric zero of all types, and empty\nstrings and containers (including strings, tuples, lists,\ndictionaries, sets and frozensets). All other values are interpreted\nas true. (See the "__nonzero__()" special method for a way to change\nthis.)\n\nThe operator "not" yields "True" if its argument is false, "False"\notherwise.\n\nThe expression "x and y" first evaluates *x*; if *x* is false, its\nvalue is returned; otherwise, *y* is evaluated and the resulting value\nis returned.\n\nThe expression "x or y" first evaluates *x*; if *x* is true, its value\nis returned; otherwise, *y* is evaluated and the resulting value is\nreturned.\n\n(Note that neither "and" nor "or" restrict the value and type they\nreturn to "False" and "True", but rather return the last evaluated\nargument. This is sometimes useful, e.g., if "s" is a string that\nshould be replaced by a default value if it is empty, the expression\n"s or \'foo\'" yields the desired value. Because "not" has to invent a\nvalue anyway, it does not bother to return a value of the same type as\nits argument, so e.g., "not \'foo\'" yields "False", not "\'\'".)\n',
21 'comparisons': u'\nComparisons\n***********\n\nUnlike C, all comparison operations in Python have the same priority,\nwhich is lower than that of any arithmetic, shifting or bitwise\noperation. Also unlike C, expressions like "a < b < c" have the\ninterpretation that is conventional in mathematics:\n\n comparison ::= or_expr ( comp_operator or_expr )*\n comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "<>" | "!="\n | "is" ["not"] | ["not"] "in"\n\nComparisons yield boolean values: "True" or "False".\n\nComparisons can be chained arbitrarily, e.g., "x < y <= z" is\nequivalent to "x < y and y <= z", except that "y" is evaluated only\nonce (but in both cases "z" is not evaluated at all when "x < y" is\nfound to be false).\n\nFormally, if *a*, *b*, *c*, ..., *y*, *z* are expressions and *op1*,\n*op2*, ..., *opN* are comparison operators, then "a op1 b op2 c ... y\nopN z" is equivalent to "a op1 b and b op2 c and ... y opN z", except\nthat each expression is evaluated at most once.\n\nNote that "a op1 b op2 c" doesn\'t imply any kind of comparison between\n*a* and *c*, so that, e.g., "x < y > z" is perfectly legal (though\nperhaps not pretty).\n\nThe forms "<>" and "!=" are equivalent; for consistency with C, "!="\nis preferred; where "!=" is mentioned below "<>" is also accepted.\nThe "<>" spelling is considered obsolescent.\n\nThe operators "<", ">", "==", ">=", "<=", and "!=" compare the values\nof two objects. The objects need not have the same type. If both are\nnumbers, they are converted to a common type. Otherwise, objects of\ndifferent types *always* compare unequal, and are ordered consistently\nbut arbitrarily. You can control comparison behavior of objects of\nnon-built-in types by defining a "__cmp__" method or rich comparison\nmethods like "__gt__", described in section Special method names.\n\n(This unusual definition of comparison was used to simplify the\ndefinition of operations like sorting and the "in" and "not in"\noperators. In the future, the comparison rules for objects of\ndifferent types are likely to change.)\n\nComparison of objects of the same type depends on the type:\n\n* Numbers are compared arithmetically.\n\n* Strings are compared lexicographically using the numeric\n equivalents (the result of the built-in function "ord()") of their\n characters. Unicode and 8-bit strings are fully interoperable in\n this behavior. [4]\n\n* Tuples and lists are compared lexicographically using comparison\
26 'customization': u'\\nBasic customization\\n*******************\\n\\nobject.__new__(cls[, ...])\\n\\n Called to create a new instance of class *cls*. "__new__()" is a\\n static method (special-cased so you need not declare it as such)\\n that takes the class of which an instance was requested as its\\n first argument. The remaining arguments are those passed to the\\n object constructor expression (the call to the class). The return\\n value of "__new__()" should be the new object instance (usually an\\n instance of *cls*).\\n\\n Typical implementations create a new instance of the class by\\n invoking the superclass\\'s "__new__()" method using\\n "super(currentclass, cls).__new__(cls[, ...])" with appropriate\\n arguments and then modifying the newly-created instance as\\n necessary before returning it.\\n\\n If "__new__()" returns an instance of *cls*, then the new\\n instance\\'s "__init__()" method will be invoked like\\n "__init__(self[, ...])", where *self* is the new instance and the\\n remaining arguments are the same as were passed to "__new__()".\\n\\n If "__new__()" does not return an instance of *cls*, then the new\\n instance\\'s "__init__()" method will not be invoked.\\n\\n "__new__()" is intended mainly to allow subclasses of immutable\\n types (like int, str, or tuple) to customize instance creation. It\\n is also commonly overridden in custom metaclasses in order to\\n customize class creation.\\n\\nobject.__init__(self[, ...])\\n\\n Called after the instance has been created (by "__new__()"), but\\n before it is returned to the caller. The arguments are those\\n passed to the class constructor expression. If a base class has an\\n "__init__()" method, the derived class\\'s "__init__()" method, if\\n any, must explicitly call it to ensure proper initialization of the\\n base class part of the instance; for example:\\n "BaseClass.__init__(self, [args...])".\\n\\n Because "__new__()" and "__init__()" work together in constructing\\n objects ("__new__()" to create it, and "__init__()" to customise\\n it), no non-"None" value may be returned by "__init__()"; doing so\\n will cause a "TypeError" to be raised at runtime.\\n\\nobject.__del__(self)\\n\\n Called when the instance is about to be destroyed. This is also\\n called a destructor. If a base class has a "__del__()" method, the\\n derived class\\'s "__del__()" method, if any, must explicitly call it\\n to ensure proper deletion of the base class part of the instance.\\n Note that it is possible (though not recommended!) for the\\n "__del__()" method to postpone destruction of the instance by\\n creating a new reference to it. It may then be called at a later\\n time when this new reference is deleted. It is not guaranteed that\\n "__del__()" methods are called for objects that still exist when\\n the interpreter exits.\\n\\n Note: "del x" doesn\\'t directly call "x.__del__()" --- the former\\n decrements the reference count for "x" by one, and the latter is\\n only called when "x"\\'s reference count reaches zero. Some common\\n situations that may prevent the reference count of an object from\\n going to zero include: circular references between objects (e.g.,\\n a doubly-linked list or a tree data structure with parent and\\n child pointers); a reference to the object on the stack frame of\\n a function that caught an exception (the traceback stored in\\n "sys.exc_traceback" keeps the stack frame alive); or a reference\\n to the object on the stack frame that raised an unhandled\\n exception in interactive mode (the traceback stored in\\n "sys.last_traceback" keeps the stack frame alive). The first\\n situation can only be remedied by explicitly breaking the cycles;\\n the latter two situations can be resolved by storing "None" in\\n "sys.exc_traceback" or "sys.last_traceback". Circular references\\n which are garbage are detected when the option cycle detector is\\n enabled (it\\'s on by default), but can only be cleaned up if there\\n are no Python-level "__del__()" methods involved. Refer to the\\n documentation for the "gc" module for more information about how\\n "__del__()" methods are handled by the cycle detector,\\n particularly the description of the "garbage" value.\\n\\n Warning: Due to the precarious circumstances under which\\n "__del__()" methods are invoked, exceptions that occur during\\n their execution are ignored, and a warning is printed to\\n "sys.stderr" instead. Also, when "__del__()" is invoked in\\n response to a module being deleted (e.g., when execution of the\\n program is done), other globals referenced by the "__del__()"\\n method may already have been deleted or in the process of being\\n torn down (e.g. the import machinery shutting down). For this\\n reason, "__del__()" methods should do the absolute minimum needed\\n to maintain external invariants. Starting with version 1.5,\\n Python guarantees that globals whose name begins with a single\\n underscore are deleted from their module before other globals are\\n deleted; if no other references to such globals exist, this may\\n help in assuring that imported modules are still available at the\\n time when the "__del__()" method is called.\\n\\n See also the "-R" command-line option.\\n\\nobject.__repr__(self)\\n\\n Called by the "repr()" built-in function and by string conversions\\n (reverse quotes) to compute the "official" string representation of\\n an object. If at all possible, this should look like a valid\\n Python expression that could be used to recreate an object with the\\n same value (given an appropriate environment). If this is not\\n possible, a string of the form "<...some useful description...>"\\n should be returned. The return value must be a string object. If a\\n class defines "__repr__()" but not "__str__()", then "__repr__()"\\n is also used when an "informal" string representation of instances\\n of that class is required.\\n\\n This is typically used for debugging, so it is important that the\\n representation is information-rich and unambiguous.\\n\\nobject.__str__(self)\\n\\n Called by the "str()" built-in function and by the "print"\\n statement to compute the "informal" string representation of an\\n object. This differs from "__repr__()" in that it does not have to\\n be a valid Python expression: a more convenient or concise\\n representation may be used instead. The return value must be a\\n string object.\\n\\nobject.__lt__(self, other)\\nobject.__le__(self, other)\\nobject.__eq__(self, other)\\nobject.__ne__(self, other)\\nobject.__gt__(self, other)\\nobject.__ge__(self, other)\\n\\n New in version 2.1.\\n\\n These are the so-called "rich comparison" methods, and are called\\n for comparison operators in preference to "__cmp__()" below. The\\n correspondence between operator symbols and method names is as\\n follows: "x<y" calls "x.__lt__(y)", "x<=y" calls "x.__le__(y)",\\n "x==y" calls "x.__eq__(y)", "x!=y" and "x<>y" call "x.__ne__(y)",\\n "x>y" calls "x.__gt__(y)", and "x>=y" calls "x.__ge__(y)".\\n\\n A rich comparison method may return the singleton "NotImplemented"\\n if it does not implement the operation for a given pair of\\n arguments. By convention, "False" and "True" are returned for a\\n successful comparison. However, these methods can return any value,\\n so if the comparison operator is used in a Boolean context (e.g.,\\n in the condition of an "if" statement), Python will call "bool()"\\n on the value to determine if the result is true or false.\\n\\n There are no implied relationships among the comparison operators.\\n The truth of "x==y" does not imply that "x!=y" is false.\\n Accordingly, when defining "__eq__()", one should also define\\n "__ne__()" so that the operators will behave as expected. See the\\n paragraph on "__hash__()" for some important notes on creating\\n *hashable* objects which support custom comparison operations and\\n are usable as dictionary keys.\\n\\n There are no swapped-argument versions of these methods (to be used\\n when the left argument does not support the operation but the right\\n argument does); rather, "__lt__()" and "__gt__()" are each other\\'s\\n reflection, "__le__()" and "__ge__()" are each other\\'s reflection,\\n and "__eq__()" and "__ne__()" are their own reflection.\\n\\n Arguments to rich comparison methods are never coerced.\\n\\n To automatically generate ordering operations from a single root\\n operation, see "functools.total_ordering()".\\n\\nobject.__cmp__(self, other)\\n\\n Called by comparison operations if rich comparison (see above) is\\n not defined. Should return a negative integer if "self < other",\\n zero if "self == other", a positive integer if "self > other". If\\n no "__cmp__()", "__eq__()" or "__ne__()" operation is defined,\\n class instances are compared by object identity ("address"). See\\n also the description of "__hash__()" for some important notes on\\n creating *hashable* objects which support custom comparison\\n operations and are usable as dictionary keys. (Note: the\\n restriction that exceptions are not propagated by "__cmp__()" has\\n been removed since Python 1.5.)\\n\\nobject.__rcmp__(self, other)\\n\\n Changed in version 2.1: No longer supported.\\n\\nobject.__hash__(self)\\n\\n Called by built-in function "hash()" and for operations on members\\n of hashed collections including "set", "frozenset", and "dict".\\n "__hash__()" should return an integer. The only required property\\n is that objects which compare equal have the same hash value; it is\\n advised to somehow mix together (e.g. using exclusive or) the hash\\n values for the components of the object that also play a part in\\n comparison of objects.\\n\\n If a class does not define a "__cmp__()" or "__eq__()" method it\\n should not define a "__hash__()" operation either; if it defines\\n "__cmp__()" or "__eq__()" but not "__hash__()", its instances will\\n not be usable in hashed collections. If a class defines mutable\\n objects and implements a "__cmp__()" or "__eq__()" method, it\\n should not implement "__hash__()", since hashable collection\\n implementations require that a object\\'s hash value is immutable (if\\n the object\\'s hash value changes, it will be in the wrong hash\\n bucket).\\n\\n User-defined classes have "__cmp__()" and "__hash__()" methods by\\n default; with them, all objects compare unequal (except with\\n themselves) and "x.__hash__()" returns a result derived from\\n "id(x)".\\n\\n Classes which inherit a "__hash__()" method from a parent class but\\n change the meaning of "__cmp__()" or "__eq__()" such that the hash\\n value returned is no longer appropriate (e.g. by switching to a\\n value-based concept of equality instead of the default identity\\n based equality) can explicitly flag themselves as being unhashable\\n by setting "__hash__ = None" in the class definition. Doing so\\n means that not only will instances of the class raise an\\n appropriate "TypeError" when a program attempts to retrieve their\\n hash value, but they will also be correctly identified as\\n unhashable when checking "isinstance(obj, collections.Hashable)"\\n (unlike classes which define their own "__hash__()" to explicitly\\n raise "TypeError").\\n\\n Changed in version 2.5: "__hash__()" may now also return a long\\n integer object; the 32-bit integer is then derived from the hash of\\n that object.\\n\\n Changed in version 2.6: "__hash__" may now be set to "None" to\\n explicitly flag instances of a class as unhashable.\\n\\nobject.__nonzero__(self)\\n\\n Called to implement truth value testing and the built-in operation\\n "bool()"; should return "False" or "True", or their integer\\n equivalents "0" or "1". When this method is not defined,\\n "__len__()" is called, if it is defined, and the object is\\n considered true if its result is nonzero. If a class defines\\n neither "__len__()" nor "__nonzero__()", all its instances are\\n considered true.\\n\\nobject.__unicode__(self)\\n\\n Called to implement "unicode()" built-in; should return a Unicode\\n object. When this method is not defined, string conversion is\\n attempted, and the result of string conversion is converted to\\n Unicode using the system default encoding.\\n', namespace
[all...]
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Demo/parser/
H A Dexample.py177 (symbol.comparison,
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Lib/test/
H A Dtest_strptime.py38 comparison = testing[self.time_tuple[tuple_position]]
41 self.assertTrue(comparison == strftime_output,
43 (error_msg, comparison, strftime_output))
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Lib/compiler/
H A Dtransformer.py618 # 'not' not_test | comparison
624 def comparison(self, nodelist): member in class:Transformer
625 # comparison: expr (comp_op expr)*
1433 symbol.comparison,
1487 symbol.comparison,
1510 symbol.comparison,
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Lib/pydoc_data/
H A Dtopics.py16 'booleans': u'\nBoolean operations\n******************\n\n or_test ::= and_test | or_test "or" and_test\n and_test ::= not_test | and_test "and" not_test\n not_test ::= comparison | "not" not_test\n\nIn the context of Boolean operations, and also when expressions are\nused by control flow statements, the following values are interpreted\nas false: ``False``, ``None``, numeric zero of all types, and empty\nstrings and containers (including strings, tuples, lists,\ndictionaries, sets and frozensets). All other values are interpreted\nas true. (See the ``__nonzero__()`` special method for a way to\nchange this.)\n\nThe operator ``not`` yields ``True`` if its argument is false,\n``False`` otherwise.\n\nThe expression ``x and y`` first evaluates *x*; if *x* is false, its\nvalue is returned; otherwise, *y* is evaluated and the resulting value\nis returned.\n\nThe expression ``x or y`` first evaluates *x*; if *x* is true, its\nvalue is returned; otherwise, *y* is evaluated and the resulting value\nis returned.\n\n(Note that neither ``and`` nor ``or`` restrict the value and type they\nreturn to ``False`` and ``True``, but rather return the last evaluated\nargument. This is sometimes useful, e.g., if ``s`` is a string that\nshould be replaced by a default value if it is empty, the expression\n``s or \'foo\'`` yields the desired value. Because ``not`` has to\ninvent a value anyway, it does not bother to return a value of the\nsame type as its argument, so e.g., ``not \'foo\'`` yields ``False``,\nnot ``\'\'``.)\n',
21 'coercion-rules': u"\nCoercion rules\n**************\n\nThis section used to document the rules for coercion. As the language\nhas evolved, the coercion rules have become hard to document\nprecisely; documenting what one version of one particular\nimplementation does is undesirable. Instead, here are some informal\nguidelines regarding coercion. In Python 3.0, coercion will not be\nsupported.\n\n* If the left operand of a % operator is a string or Unicode object,\n no coercion takes place and the string formatting operation is\n invoked instead.\n\n* It is no longer recommended to define a coercion operation. Mixed-\n mode operations on types that don't define coercion pass the\n original arguments to the operation.\n\n* New-style classes (those derived from ``object``) never invoke the\n ``__coerce__()`` method in response to a binary operator; the only\n time ``__coerce__()`` is invoked is when the built-in function\n ``coerce()`` is called.\n\n* For most intents and purposes, an operator that returns\n ``NotImplemented`` is treated the same as one that is not\n implemented at all.\n\n* Below, ``__op__()`` and ``__rop__()`` are used to signify the\n generic method names corresponding to an operator; ``__iop__()`` is\n used for the corresponding in-place operator. For example, for the\n operator '``+``', ``__add__()`` and ``__radd__()`` are used for the\n left and right variant of the binary operator, and ``__iadd__()``\n for the in-place variant.\n\n* For objects *x* and *y*, first ``x.__op__(y)`` is tried. If this is\n not implemented or returns ``NotImplemented``, ``y.__rop__(x)`` is\n tried. If this is also not implemented or returns\n ``NotImplemented``, a ``TypeError`` exception is raised. But see\n the following exception:\n\n* Exception to the previous item: if the left operand is an instance\n of a built-in type or a new-style class, and the right operand is an\n instance of a proper subclass of that type or class and overrides\n the base's ``__rop__()`` method, the right operand's ``__rop__()``\n method is tried *before* the left operand's ``__op__()`` method.\n\n This is done so that a subclass can completely override binary\n operators. Otherwise, the left operand's ``__op__()`` method would\n always accept the right operand: when an instance of a given class\n is expected, an instance of a subclass of that class is always\n acceptable.\n\n* When either operand type defines a coercion, this coercion is called\n before that type's ``__op__()`` or ``__rop__()`` method is called,\n but no sooner. If the coercion returns an object of a different\n type for the operand whose coercion is invoked, part of the process\n is redone using the new object.\n\n* When an in-place operator (like '``+=``') is used, if the left\n operand implements ``__iop__()``, it is invoked without any\n coercion. When the operation falls back to ``__op__()`` and/or\n ``__rop__()``, the normal coercion rules apply.\n\n* In ``x + y``, if *x* is a sequence that implements sequence\n concatenation, sequence concatenation is invoked.\n\n* In ``x * y``, if one operator is a sequence that implements sequence\n repetition, and the other is an integer (``int`` or ``long``),\n sequence repetition is invoked.\n\n* Rich comparisons (implemented by methods ``__eq__()`` and so on)\n never use coercion. Three-way comparison (implemented by\n ``__cmp__()``) does use coercion under the same conditions as other\n binary operations use it.\n\n* In the current implementation, the built-in numeric types ``int``,\n ``long``, ``float``, and ``complex`` do not use coercion. All these\n types implement a ``__coerce__()`` method, for use by the built-in\n ``coerce()`` function.\n\n Changed in version 2.7.\n",
22 'comparisons': u'\nComparisons\n***********\n\nUnlike C, all comparison operations in Python have the same priority,\nwhich is lower than that of any arithmetic, shifting or bitwise\noperation. Also unlike C, expressions like ``a < b < c`` have the\ninterpretation that is conventional in mathematics:\n\n comparison ::= or_expr ( comp_operator or_expr )*\n comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "<>" | "!="\n | "is" ["not"] | ["not"] "in"\n\nComparisons yield boolean values: ``True`` or ``False``.\n\nComparisons can be chained arbitrarily, e.g., ``x < y <= z`` is\nequivalent to ``x < y and y <= z``, except that ``y`` is evaluated\nonly once (but in both cases ``z`` is not evaluated at all when ``x <\ny`` is found to be false).\n\nFormally, if *a*, *b*, *c*, ..., *y*, *z* are expressions and *op1*,\n*op2*, ..., *opN* are comparison operators, then ``a op1 b op2 c ... y\nopN z`` is equivalent to ``a op1 b and b op2 c and ... y opN z``,\nexcept that each expression is evaluated at most once.\n\nNote that ``a op1 b op2 c`` doesn\'t imply any kind of comparison\nbetween *a* and *c*, so that, e.g., ``x < y > z`` is perfectly legal\n(though perhaps not pretty).\n\nThe forms ``<>`` and ``!=`` are equivalent; for consistency with C,\n``!=`` is preferred; where ``!=`` is mentioned below ``<>`` is also\naccepted. The ``<>`` spelling is considered obsolescent.\n\nThe operators ``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare\nthe values of two objects. The objects need not have the same type.\nIf both are numbers, they are converted to a common type. Otherwise,\nobjects of different types *always* compare unequal, and are ordered\nconsistently but arbitrarily. You can control comparison behavior of\nobjects of non-built-in types by defining a ``__cmp__`` method or rich\ncomparison methods like ``__gt__``, described in section *Special\nmethod names*.\n\n(This unusual definition of comparison was used to simplify the\ndefinition of operations like sorting and the ``in`` and ``not in``\noperators. In the future, the comparison rules for objects of\ndifferent types are likely to change.)\n\nComparison of objects of the same type depends on the type:\n\n* Numbers are compared arithmetically.\n\n* Strings are compared lexicographically using the numeric equivalents\n (the result of the built-in function ``ord()``) of their characters.\n Unicode and 8-bit strings are fully interoperable in this behavior.\n [4]\n\n* Tuples and lists are compared lexicographically using comparison o
27 'customization': u'\\nBasic customization\\n*******************\\n\\nobject.__new__(cls[, ...])\\n\\n Called to create a new instance of class *cls*. ``__new__()`` is a\\n static method (special-cased so you need not declare it as such)\\n that takes the class of which an instance was requested as its\\n first argument. The remaining arguments are those passed to the\\n object constructor expression (the call to the class). The return\\n value of ``__new__()`` should be the new object instance (usually\\n an instance of *cls*).\\n\\n Typical implementations create a new instance of the class by\\n invoking the superclass\\'s ``__new__()`` method using\\n ``super(currentclass, cls).__new__(cls[, ...])`` with appropriate\\n arguments and then modifying the newly-created instance as\\n necessary before returning it.\\n\\n If ``__new__()`` returns an instance of *cls*, then the new\\n instance\\'s ``__init__()`` method will be invoked like\\n ``__init__(self[, ...])``, where *self* is the new instance and the\\n remaining arguments are the same as were passed to ``__new__()``.\\n\\n If ``__new__()`` does not return an instance of *cls*, then the new\\n instance\\'s ``__init__()`` method will not be invoked.\\n\\n ``__new__()`` is intended mainly to allow subclasses of immutable\\n types (like int, str, or tuple) to customize instance creation. It\\n is also commonly overridden in custom metaclasses in order to\\n customize class creation.\\n\\nobject.__init__(self[, ...])\\n\\n Called when the instance is created. The arguments are those\\n passed to the class constructor expression. If a base class has an\\n ``__init__()`` method, the derived class\\'s ``__init__()`` method,\\n if any, must explicitly call it to ensure proper initialization of\\n the base class part of the instance; for example:\\n ``BaseClass.__init__(self, [args...])``. As a special constraint\\n on constructors, no value may be returned; doing so will cause a\\n ``TypeError`` to be raised at runtime.\\n\\nobject.__del__(self)\\n\\n Called when the instance is about to be destroyed. This is also\\n called a destructor. If a base class has a ``__del__()`` method,\\n the derived class\\'s ``__del__()`` method, if any, must explicitly\\n call it to ensure proper deletion of the base class part of the\\n instance. Note that it is possible (though not recommended!) for\\n the ``__del__()`` method to postpone destruction of the instance by\\n creating a new reference to it. It may then be called at a later\\n time when this new reference is deleted. It is not guaranteed that\\n ``__del__()`` methods are called for objects that still exist when\\n the interpreter exits.\\n\\n Note: ``del x`` doesn\\'t directly call ``x.__del__()`` --- the former\\n decrements the reference count for ``x`` by one, and the latter\\n is only called when ``x``\\'s reference count reaches zero. Some\\n common situations that may prevent the reference count of an\\n object from going to zero include: circular references between\\n objects (e.g., a doubly-linked list or a tree data structure with\\n parent and child pointers); a reference to the object on the\\n stack frame of a function that caught an exception (the traceback\\n stored in ``sys.exc_traceback`` keeps the stack frame alive); or\\n a reference to the object on the stack frame that raised an\\n unhandled exception in interactive mode (the traceback stored in\\n ``sys.last_traceback`` keeps the stack frame alive). The first\\n situation can only be remedied by explicitly breaking the cycles;\\n the latter two situations can be resolved by storing ``None`` in\\n ``sys.exc_traceback`` or ``sys.last_traceback``. Circular\\n references which are garbage are detected when the option cycle\\n detector is enabled (it\\'s on by default), but can only be cleaned\\n up if there are no Python-level ``__del__()`` methods involved.\\n Refer to the documentation for the ``gc`` module for more\\n information about how ``__del__()`` methods are handled by the\\n cycle detector, particularly the description of the ``garbage``\\n value.\\n\\n Warning: Due to the precarious circumstances under which ``__del__()``\\n methods are invoked, exceptions that occur during their execution\\n are ignored, and a warning is printed to ``sys.stderr`` instead.\\n Also, when ``__del__()`` is invoked in response to a module being\\n deleted (e.g., when execution of the program is done), other\\n globals referenced by the ``__del__()`` method may already have\\n been deleted or in the process of being torn down (e.g. the\\n import machinery shutting down). For this reason, ``__del__()``\\n methods should do the absolute minimum needed to maintain\\n external invariants. Starting with version 1.5, Python\\n guarantees that globals whose name begins with a single\\n underscore are deleted from their module before other globals are\\n deleted; if no other references to such globals exist, this may\\n help in assuring that imported modules are still available at the\\n time when the ``__del__()`` method is called.\\n\\nobject.__repr__(self)\\n\\n Called by the ``repr()`` built-in function and by string\\n conversions (reverse quotes) to compute the "official" string\\n representation of an object. If at all possible, this should look\\n like a valid Python expression that could be used to recreate an\\n object with the same value (given an appropriate environment). If\\n this is not possible, a string of the form ``<...some useful\\n description...>`` should be returned. The return value must be a\\n string object. If a class defines ``__repr__()`` but not\\n ``__str__()``, then ``__repr__()`` is also used when an "informal"\\n string representation of instances of that class is required.\\n\\n This is typically used for debugging, so it is important that the\\n representation is information-rich and unambiguous.\\n\\nobject.__str__(self)\\n\\n Called by the ``str()`` built-in function and by the ``print``\\n statement to compute the "informal" string representation of an\\n object. This differs from ``__repr__()`` in that it does not have\\n to be a valid Python expression: a more convenient or concise\\n representation may be used instead. The return value must be a\\n string object.\\n\\nobject.__lt__(self, other)\\nobject.__le__(self, other)\\nobject.__eq__(self, other)\\nobject.__ne__(self, other)\\nobject.__gt__(self, other)\\nobject.__ge__(self, other)\\n\\n New in version 2.1.\\n\\n These are the so-called "rich comparison" methods, and are called\\n for comparison operators in preference to ``__cmp__()`` below. The\\n correspondence between operator symbols and method names is as\\n follows: ``x<y`` calls ``x.__lt__(y)``, ``x<=y`` calls\\n ``x.__le__(y)``, ``x==y`` calls ``x.__eq__(y)``, ``x!=y`` and\\n ``x<>y`` call ``x.__ne__(y)``, ``x>y`` calls ``x.__gt__(y)``, and\\n ``x>=y`` calls ``x.__ge__(y)``.\\n\\n A rich comparison method may return the singleton\\n ``NotImplemented`` if it does not implement the operation for a\\n given pair of arguments. By convention, ``False`` and ``True`` are\\n returned for a successful comparison. However, these methods can\\n return any value, so if the comparison operator is used in a\\n Boolean context (e.g., in the condition of an ``if`` statement),\\n Python will call ``bool()`` on the value to determine if the result\\n is true or false.\\n\\n There are no implied relationships among the comparison operators.\\n The truth of ``x==y`` does not imply that ``x!=y`` is false.\\n Accordingly, when defining ``__eq__()``, one should also define\\n ``__ne__()`` so that the operators will behave as expected. See\\n the paragraph on ``__hash__()`` for some important notes on\\n creating *hashable* objects which support custom comparison\\n operations and are usable as dictionary keys.\\n\\n There are no swapped-argument versions of these methods (to be used\\n when the left argument does not support the operation but the right\\n argument does); rather, ``__lt__()`` and ``__gt__()`` are each\\n other\\'s reflection, ``__le__()`` and ``__ge__()`` are each other\\'s\\n reflection, and ``__eq__()`` and ``__ne__()`` are their own\\n reflection.\\n\\n Arguments to rich comparison methods are never coerced.\\n\\n To automatically generate ordering operations from a single root\\n operation, see ``functools.total_ordering()``.\\n\\nobject.__cmp__(self, other)\\n\\n Called by comparison operations if rich comparison (see above) is\\n not defined. Should return a negative integer if ``self < other``,\\n zero if ``self == other``, a positive integer if ``self > other``.\\n If no ``__cmp__()``, ``__eq__()`` or ``__ne__()`` operation is\\n defined, class instances are compared by object identity\\n ("address"). See also the description of ``__hash__()`` for some\\n important notes on creating *hashable* objects which support custom\\n comparison operations and are usable as dictionary keys. (Note: the\\n restriction that exceptions are not propagated by ``__cmp__()`` has\\n been removed since Python 1.5.)\\n\\nobject.__rcmp__(self, other)\\n\\n Changed in version 2.1: No longer supported.\\n\\nobject.__hash__(self)\\n\\n Called by built-in function ``hash()`` and for operations on\\n members of hashed collections including ``set``, ``frozenset``, and\\n ``dict``. ``__hash__()`` should return an integer. The only\\n required property is that objects which compare equal have the same\\n hash value; it is advised to somehow mix together (e.g. using\\n exclusive or) the hash values for the components of the object that\\n also play a part in comparison of objects.\\n\\n If a class does not define a ``__cmp__()`` or ``__eq__()`` method\\n it should not define a ``__hash__()`` operation either; if it\\n defines ``__cmp__()`` or ``__eq__()`` but not ``__hash__()``, its\\n instances will not be usable in hashed collections. If a class\\n defines mutable objects and implements a ``__cmp__()`` or\\n ``__eq__()`` method, it should not implement ``__hash__()``, since\\n hashable collection implementations require that a object\\'s hash\\n value is immutable (if the object\\'s hash value changes, it will be\\n in the wrong hash bucket).\\n\\n User-defined classes have ``__cmp__()`` and ``__hash__()`` methods\\n by default; with them, all objects compare unequal (except with\\n themselves) and ``x.__hash__()`` returns ``id(x)``.\\n\\n Classes which inherit a ``__hash__()`` method from a parent class\\n but change the meaning of ``__cmp__()`` or ``__eq__()`` such that\\n the hash value returned is no longer appropriate (e.g. by switching\\n to a value-based concept of equality instead of the default\\n identity based equality) can explicitly flag themselves as being\\n unhashable by setting ``__hash__ = None`` in the class definition.\\n Doing so means that not only will instances of the class raise an\\n appropriate ``TypeError`` when a program attempts to retrieve their\\n hash value, but they will also be correctly identified as\\n unhashable when checking ``isinstance(obj, collections.Hashable)``\\n (unlike classes which define their own ``__hash__()`` to explicitly\\n raise ``TypeError``).\\n\\n Changed in version 2.5: ``__hash__()`` may now also return a long\\n integer object; the 32-bit integer is then derived from the hash of\\n that object.\\n\\n Changed in version 2.6: ``__hash__`` may now be set to ``None`` to\\n explicitly flag instances of a class as unhashable.\\n\\nobject.__nonzero__(self)\\n\\n Called to implement truth value testing and the built-in operation\\n ``bool()``; should return ``False`` or ``True``, or their integer\\n equivalents ``0`` or ``1``. When this method is not defined,\\n ``__len__()`` is called, if it is defined, and the object is\\n considered true if its result is nonzero. If a class defines\\n neither ``__len__()`` nor ``__nonzero__()``, all its instances are\\n considered true.\\n\\nobject.__unicode__(self)\\n\\n Called to implement ``unicode()`` built-in; should return a Unicode\\n object. When this method is not defined, string conversion is\\n attempted, and the result of string conversion is converted to\\n Unicode using the system default encoding.\\n', namespace
[all...]
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.10/Modules/
H A Dparsermodule.c959 VALIDATER(not_test); VALIDATER(comparison); variable
2260 int res = (validate_ntype(tree, comparison)
2305 err_string("illegal comparison operator type");
2317 err_string("unknown comparison operator");
3248 case comparison:
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Modules/
H A Dparsermodule.c930 VALIDATER(not_test); VALIDATER(comparison); variable
2231 int res = (validate_ntype(tree, comparison)
2276 err_string("illegal comparison operator type");
2288 err_string("unknown comparison operator");
3219 case comparison:
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.10/Python/
H A Dast.c449 expr_name = "comparison";
1828 not_test: 'not' not_test | comparison
1829 comparison: expr (comp_op expr)*
1895 case comparison:
/device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Python/
H A Dast.c449 expr_name = "comparison";
1823 not_test: 'not' not_test | comparison
1824 comparison: expr (comp_op expr)*
1890 case comparison:

Completed in 136 milliseconds