Arbitrary dunder attributes (was Re: odd difference calling function from class or instance variable)
Terry Reedy
tjreedy at udel.edu
Wed Aug 13 15:15:14 EDT 2014
On 8/13/2014 5:51 AM, Chris Angelico wrote:
> On Wed, Aug 13, 2014 at 7:06 PM, GregS <not at my.real.address.com> wrote:
>> When I assign the reference as a class variable, the reference has __self__
>> set, too, so I get an extra argument passed to the function. If I assign
>> the reference as an instance variable, then __self__ is unset so no extra
>> argument.
>
> Spin-off from Greg's thread.
>
> The bound method object stores a reference to the original object (the
> thing that becomes the first argument to the target function) in
> __self__ (and the function in __func__). ISTM this ought to be _self
> (and _func), as it's intended to be private; is it really something
> that has language-level significance on par with __lt__ and so on?
In 3.0, the iterator protocol .next became .__next__ for consistency
with other syntax dunder methods.
In 2.x, bound python-coded functions had im_func and im_self (and
im_class for the class im_func was attached to, which has no equivalent
in 3.x). Bound C-coded functions, such as [].sort, had and still have
__self__ instead of im_self (and no equivalent of im_func/__func__). I
presume this difference goes back to the gulf between C-coded types and
Python-coded old-style classes. With old-style classes gone, im_class
went and it made sense to consistently use __self__ instead of sometimes
im_self (and change im_func to __func__ alone with it).
In 3.0, function attributes were also dunderized. This was needed once
function namespaces were unfrozen and users allowed to add possibly
conflicting function attributes.
>>> dir(lambda:0) #2.7
['__call__', '__class__', '__closure__', '__code__', '__defaults__',
'__delattr__', '__dict__', '__doc__', '__format__', '__get__',
'__getattribute__', '__globals__', '__hash__', '__init__', '__module__',
'__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__sizeof__', '__str__', '__subclasshook__',
'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc',
'func_globals', 'func_name']
(In 2.7, many of the func attributes are duplicates: __code__ ==
func_code, etc, though this might not have always been true.)
>>> dir(lambda:0)
['__annotations__', '__call__', '__class__', '__closure__', '__code__',
'__defaults__', '__delattr__', '__dict__', '__dir__', '__doc__',
'__eq__', '__format__', '__ge__', '__get__', '__getattribute__',
'__globals__', '__gt__', '__hash__', '__init__', '__kwdefaults__',
'__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__',
'__qualname__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__sizeof__', '__str__', '__subclasshook__']
The function specific attributes are documented in
https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
The same was not done for 'internal types': code objects and co_, frame
objects and f_, traceback objects and tb_. Their namespaces are still
frozen.
--
Terry Jan Reedy
More information about the Python-list
mailing list