Arbitrary dunder attributes (was Re: odd difference calling function from class or instance variable)

[Terry Reedy]

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