.. c:function:: int PyDict_DelItem(PyObject *p, PyObject *key)
- Remove the entry in dictionary *p* with key *key*. *key* must be hashable;
+ Remove the entry in dictionary *p* with key *key*. *key* must be :term:`hashable`;
if it isn't, :exc:`TypeError` is raised.
If *key* is not in the dictionary, :exc:`KeyError` is raised.
Return ``0`` on success or ``-1`` on failure.
.. c:function:: Py_hash_t PyObject_HashNotImplemented(PyObject *o)
- Set a :exc:`TypeError` indicating that ``type(o)`` is not hashable and return ``-1``.
+ Set a :exc:`TypeError` indicating that ``type(o)`` is not :term:`hashable` and return ``-1``.
This function receives special treatment when stored in a ``tp_hash`` slot,
allowing a type to explicitly indicate to the interpreter that it is not
hashable.
instances accumulate, so too will the accumulated method results. They
can grow without bound.
-The *lru_cache* approach works with methods that have hashable
+The *lru_cache* approach works with methods that have :term:`hashable`
arguments. It creates a reference to the instance unless special
efforts are made to pass in weak references.
ABCs; these can, of course, be further derived. In addition, the
:mod:`collections.abc` submodule has some ABCs that can be used to test whether
a class or instance provides a particular interface, for example, if it is
-hashable or if it is a mapping.
+:term:`hashable` or if it is a mapping.
This module provides the metaclass :class:`ABCMeta` for defining ABCs and
This module provides :term:`abstract base classes <abstract base class>` that
can be used to test whether a class provides a particular interface; for
-example, whether it is hashable or whether it is a mapping.
+example, whether it is :term:`hashable` or whether it is a mapping.
An :func:`issubclass` or :func:`isinstance` test for an interface works in one
of three ways.
(3)
The :class:`Set` mixin provides a :meth:`_hash` method to compute a hash value
for the set; however, :meth:`__hash__` is not defined because not all sets
- are hashable or immutable. To add set hashability using mixins,
+ are :term:`hashable` or immutable. To add set hashability using mixins,
inherit from both :meth:`Set` and :meth:`Hashable`, then define
``__hash__ = Set._hash``.
:func:`namedtuple` factory function for creating tuple subclasses with named fields
:class:`deque` list-like container with fast appends and pops on either end
:class:`ChainMap` dict-like class for creating a single view of multiple mappings
-:class:`Counter` dict subclass for counting hashable objects
+:class:`Counter` dict subclass for counting :term:`hashable` objects
:class:`OrderedDict` dict subclass that remembers the order entries were added
:class:`defaultdict` dict subclass that calls a factory function to supply missing values
:class:`UserDict` wrapper around dictionary objects for easier dict subclassing
.. class:: Counter([iterable-or-mapping])
- A :class:`Counter` is a :class:`dict` subclass for counting hashable objects.
+ A :class:`Counter` is a :class:`dict` subclass for counting :term:`hashable` objects.
It is a collection where elements are stored as dictionary keys
and their counts are stored as dictionary values. Counts are allowed to be
any integer value including zero or negative counts. The :class:`Counter`
share these common features:
- Objects of these types are immutable.
-- Objects of these types are hashable, meaning that they can be used as
+- Objects of these types are :term:`hashable`, meaning that they can be used as
dictionary keys.
- Objects of these types support efficient pickling via the :mod:`pickle` module.
The :class:`Fraction` class inherits from the abstract base class
:class:`numbers.Rational`, and implements all of the methods and
- operations from that class. :class:`Fraction` instances are hashable,
+ operations from that class. :class:`Fraction` instances are :term:`hashable`,
and should be treated as immutable. In addition,
:class:`Fraction` has the following properties and methods:
threads.
Since a dictionary is used to cache results, the positional and keyword
- arguments to the function must be hashable.
+ arguments to the function must be :term:`hashable`.
Distinct argument patterns may be considered to be distinct calls with
separate cache entries. For example, ``f(a=1, b=2)`` and ``f(b=2, a=1)``
.. class:: TopologicalSorter(graph=None)
- Provides functionality to topologically sort a graph of hashable nodes.
+ Provides functionality to topologically sort a graph of :term:`hashable` nodes.
A topological order is a linear ordering of the vertices in a graph such that
for every directed edge u -> v from vertex u to vertex v, vertex u comes
.. method:: add(node, *predecessors)
Add a new node and its predecessors to the graph. Both the *node* and all
- elements in *predecessors* must be hashable.
+ elements in *predecessors* must be :term:`hashable`.
If called multiple times with the same node argument, the set of
dependencies will be the union of all dependencies passed in.
modified copy.
.. versionchanged:: 3.5
- Signature objects are picklable and hashable.
+ Signature objects are picklable and :term:`hashable`.
.. attribute:: Signature.empty
you can use :meth:`Parameter.replace` to create a modified copy.
.. versionchanged:: 3.5
- Parameter objects are picklable and hashable.
+ Parameter objects are picklable and :term:`hashable`.
.. attribute:: Parameter.empty
return g
The items can be any type accepted by the operand's :meth:`__getitem__`
- method. Dictionaries accept any hashable value. Lists, tuples, and
+ method. Dictionaries accept any :term:`hashable` value. Lists, tuples, and
strings accept an index or a slice:
>>> itemgetter(1)('ABCDEFG')
General properties
^^^^^^^^^^^^^^^^^^
-Paths are immutable and hashable. Paths of a same flavour are comparable
+Paths are immutable and :term:`hashable`. Paths of a same flavour are comparable
and orderable. These properties respect the flavour's case-folding
semantics::
>>> data
bytearray(b'z1spam')
- One-dimensional memoryviews of hashable (read-only) types with formats
+ One-dimensional memoryviews of :term:`hashable` (read-only) types with formats
'B', 'b' or 'c' are also hashable. The hash is defined as
``hash(m) == hash(m.tobytes())``::
.. versionchanged:: 3.3
One-dimensional memoryviews can now be sliced.
- One-dimensional memoryviews with formats 'B', 'b' or 'c' are now hashable.
+ One-dimensional memoryviews with formats 'B', 'b' or 'c' are now :term:`hashable`.
.. versionchanged:: 3.4
memoryview is now registered automatically with
.. versionadded:: 3.10
-Keys views are set-like since their entries are unique and hashable. If all
+Keys views are set-like since their entries are unique and :term:`hashable`. If all
values are hashable, so that ``(key, value)`` pairs are unique and hashable,
then the items view is also set-like. (Values views are not treated as set-like
since the entries are generally not unique.) For set-like views, all of the
A user-defined generic class can have ABCs as base classes without a metaclass
conflict. Generic metaclasses are not supported. The outcome of parameterizing
-generics is cached, and most types in the typing module are hashable and
+generics is cached, and most types in the typing module are :term:`hashable` and
comparable for equality.
:meth:`__hash__`, its instances will not be usable as items in hashable
collections. If a class defines mutable objects and implements an
:meth:`__eq__` method, it should not implement :meth:`__hash__`, since the
- implementation of hashable collections requires that a key's hash value is
+ implementation of :term:`hashable` collections requires that a key's hash value is
immutable (if the object's hash value changes, it will be in the wrong hash
bucket).
projects / thirdparty / Python / cpython.git / commitdiff
