Removed an unnecessary and confusing paragraph from the namedtuple docs.
This commit is contained in:
parent
63c77b6175
commit
9bba7b7085
|
@ -526,16 +526,7 @@ a fixed-width print format::
|
||||||
Point: x= 3.000 y= 4.000 hypot= 5.000
|
Point: x= 3.000 y= 4.000 hypot= 5.000
|
||||||
Point: x=14.000 y= 0.714 hypot=14.018
|
Point: x=14.000 y= 0.714 hypot=14.018
|
||||||
|
|
||||||
Another use for subclassing is to replace performance critcal methods with
|
The subclass shown above sets ``__slots__`` to an empty tuple. This keeps
|
||||||
faster versions that bypass error-checking::
|
|
||||||
|
|
||||||
class Point(namedtuple('Point', 'x y')):
|
|
||||||
__slots__ = ()
|
|
||||||
_make = classmethod(tuple.__new__)
|
|
||||||
def _replace(self, _map=map, **kwds):
|
|
||||||
return self._make(_map(kwds.get, ('x', 'y'), self))
|
|
||||||
|
|
||||||
The subclasses shown above set ``__slots__`` to an empty tuple. This keeps
|
|
||||||
keep memory requirements low by preventing the creation of instance dictionaries.
|
keep memory requirements low by preventing the creation of instance dictionaries.
|
||||||
|
|
||||||
Subclassing is not useful for adding new, stored fields. Instead, simply
|
Subclassing is not useful for adding new, stored fields. Instead, simply
|
||||||
|
|
Loading…
Reference in New Issue