← Back to branch summary

~ubuntu-branches/ubuntu/lucid/python2.6/lucid

« back to all changes in this revision

Viewing changes to Doc/reference/expressions.rst

  • Committer: Bazaar Package Importer
  • Author(s): Matthias Klose
  • Date: 2010-03-11 13:30:19 UTC
  • mto: (10.1.13 sid)
  • mto: This revision was merged to the branch mainline in revision 44.
  • Revision ID: james.westby@ubuntu.com-20100311133019-sblbooa3uqrkoe70
Tags: upstream-2.6.5~rc2
Import upstream version 2.6.5~rc2

Show diffs side-by-side

added added

removed removed

Lines of Context:
Doc/reference/expressions.rst
663
663
raised.  Otherwise, the list of filled slots is used as the argument list for
664
664
the call.
665
665
 
666
 
.. note::
 
666
.. impl-detail::
667
667
 
668
 
   An implementation may provide builtin functions whose positional parameters do
669
 
   not have names, even if they are 'named' for the purpose of documentation, and
670
 
   which therefore cannot be supplied by keyword.  In CPython, this is the case for
671
 
   functions implemented in C that use :cfunc:`PyArg_ParseTuple` to parse their
672
 
   arguments.
 
668
   An implementation may provide built-in functions whose positional parameters
 
669
   do not have names, even if they are 'named' for the purpose of documentation,
 
670
   and which therefore cannot be supplied by keyword.  In CPython, this is the
 
671
   case for functions implemented in C that use :cfunc:`PyArg_ParseTuple` to
 
672
   parse their arguments.
673
673
 
674
674
If there are more positional arguments than there are formal parameter slots, a
675
675
:exc:`TypeError` exception is raised, unless a formal parameter using the syntax
1032
1032
values of two objects.  The objects need not have the same type. If both are
1033
1033
numbers, they are converted to a common type.  Otherwise, objects of different
1034
1034
types *always* compare unequal, and are ordered consistently but arbitrarily.
1035
 
You can control comparison behavior of objects of non-builtin types by defining
 
1035
You can control comparison behavior of objects of non-built-in types by defining
1036
1036
a ``__cmp__`` method or rich comparison methods like ``__gt__``, described in
1037
1037
section :ref:`specialnames`.
1038
1038
 
1063
1063
  lists compare equal. [#]_ Outcomes other than equality are resolved
1064
1064
  consistently, but are not otherwise defined. [#]_
1065
1065
 
1066
 
* Most other objects of builtin types compare unequal unless they are the same
 
1066
* Most other objects of built-in types compare unequal unless they are the same
1067
1067
  object; the choice whether one object is considered smaller or larger than
1068
1068
  another one is made arbitrarily but consistently within one execution of a
1069
1069
  program.
1070
1070
 
 
1071
.. _membership-test-details:
 
1072
 
1071
1073
The operators :keyword:`in` and :keyword:`not in` test for collection
1072
1074
membership.  ``x in s`` evaluates to true if *x* is a member of the collection
1073
1075
*s*, and false otherwise.  ``x not in s`` returns the negation of ``x in s``.
1092
1094
For user-defined classes which define the :meth:`__contains__` method, ``x in
1093
1095
y`` is true if and only if ``y.__contains__(x)`` is true.
1094
1096
 
1095
 
For user-defined classes which do not define :meth:`__contains__` and do define
 
1097
For user-defined classes which do not define :meth:`__contains__` but do define
 
1098
:meth:`__iter__`, ``x in y`` is true if some value ``z`` with ``x == z`` is
 
1099
produced while iterating over ``y``.  If an exception is raised during the
 
1100
iteration, it is as if :keyword:`in` raised that exception.
 
1101
 
 
1102
Lastly, the old-style iteration protocol is tried: if a class defines
1096
1103
:meth:`__getitem__`, ``x in y`` is true if and only if there is a non-negative
1097
1104
integer index *i* such that ``x == y[i]``, and all lower integer indices do not
1098
1105
raise :exc:`IndexError` exception. (If any other exception is raised, it is as