Implement all of the special methods

[eric-wieser]

Looking through all the ones defined in https://raw.githubusercontent.com/python/cpython/3.8/Doc/reference/datamodel.rst, we get:

List

object.__abs__
object.__add__
object.__aenter__
object.__aexit__
object.__aiter__
object.__and__
object.__anext__
object.__await__
object.__bool__
object.__bytes__
object.__call__
object.__ceil__
object.__class_getitem__
object.__complex__
object.__contains__
object.__del__
object.__delattr__
object.__delete__
object.__delitem__
object.__dict__
object.__dir__
object.__divmod__
object.__enter__
object.__eq__
object.__exit__
object.__float__
object.__floor__
object.__floordiv__
object.__format__
object.__ge__
object.__get__
object.__getattr__
object.__getattribute__
object.__getitem__
object.__gt__
object.__hash__
object.__iadd__
object.__iand__
object.__ifloordiv__
object.__ilshift__
object.__imatmul__
object.__imod__
object.__imul__
object.__index__
object.__init__
object.__init_subclass__
object.__int__
object.__invert__
object.__ior__
object.__ipow__
object.__irshift__
object.__isub__
object.__iter__
object.__itruediv__
object.__ixor__
object.__le__
object.__len__
object.__length_hint__
object.__lshift__
object.__lt__
object.__matmul__
object.__missing__
object.__mod__
object.__mul__
object.__ne__
object.__neg__
object.__new__
object.__or__
object.__pos__
object.__pow__
object.__radd__
object.__rand__
object.__rdivmod__
object.__repr__
object.__reversed__
object.__rfloordiv__
object.__rlshift__
object.__rmatmul__
object.__rmod__
object.__rmul__
object.__ror__
object.__round__
object.__rpow__
object.__rrshift__
object.__rshift__
object.__rsub__
object.__rtruediv__
object.__rxor__
object.__set__
object.__set_name__
object.__setattr__
object.__setitem__
object.__slots__
object.__str__
object.__sub__
object.__truediv__
object.__trunc__
object.__xor__

The ones not yet implemented are listed in

prettyspecialmethods/tests/test_implemented.py

Lines 113 to 143 in 316ec3a

	unimplemented_ops = dict(
	# not implemented
	inplace_ops={re.sub('^__', '__i', m) for m in all_methods} & all_methods,
	# typically redundant
	reverse_ops={re.sub('^__', '__r', m) for m in all_methods} & all_methods,
	# diffult to show clearly
	descriptor_ops={'__get__', '__set__', '__delete__', '__set_name__'},
	# unclear whether to apply the formatting to enter or exit
	with_ops={'__enter__', '__exit__'},
	async_with_ops={'__aenter__', '__aexit__'},
	# no aiter or anext builtin
	async_iter_ops={'__aiter__', '__anext__'},
	# difficult to represent
	other_ops={
	'__await__',
	'__class_getitem__',
	'__del__',
	'__dict__',
	'__getattribute__',
	'__init__',
	'__init_subclass__',
	'__missing__',
	'__new__',
	'__slots__',
	},
	)

[johnpmcconnell]

Suggestion for __enter__ and __exit__: just show one with statement and combine the docstrings from both methods into a single block.

[johnpmcconnell]

Scratch my previous idea. It goes very poorly without autodoc (and this extension is designed to be able to work without it), although maybe the two could be combined in an autodoc event for that use case.

For general usage, I think __enter__ is the better choice here, since its return value gets stored in the context variable, meaning its return type might need to be incorporated into the documentation somehow.

That said, __enter__ has the interesting position of being hidden behind the with so completely that you usually see the object's constructor in code instead of a variable containing the object (with MyCtxMngr() as cm: instead of with cm:). This means with probably requires much more flexibility in configuring how it's presented than the other special methods.