[Python-ideas] Deprecate dunder functions from operator module

Ethan Furman ethan at stoneleaf.us
Tue Nov 4 05:04:10 CET 2014


On 11/03/2014 07:57 PM, Steven D'Aprano wrote:
> On Sat, Nov 01, 2014 at 01:02:19PM -0700, Ethan Furman wrote:
>> On 10/29/2014 06:38 PM, Ethan Furman wrote:
>>> On 10/29/2014 05:53 PM, Steven D'Aprano wrote:
>>>>
>>>> I propose a few things:
>>>>
>>>> * institute a policy that, in the event of a new function being added
>>>>    to the operator module, only the dunderless version will be added;
>>>>
>>>> * change the documentation to make it clear that the dunderless
>>>>    versions should be used, rather than merely being "convenience"
>>>>    functions;
>>>>
>>>> * add a prominent note that the dunder versions exist for backwards
>>>>    compatibility only and should not be used in new code.
>>>
>>> +1
>>
>> Actually, make that -1.
>>
>> I'm just crafting some tests to explore how NotImplemented impacts various
>> classes, and the dunder versions make the whole thing much nicer.
>
> I'm surprised. I can't imagine dunder names making anything look
> nicer. It sounds like you are writing "operator.__add__" instead
> of "operator.add", which doesn't look nicer to me.

The dunder versions are being used to check if a particular method is in a type's dictionary, to see how the subclass 
should be tailored for a test.  Without the dunder versions I would have had to create my own mapping between dunder and 
dunderless names.


> Can you show me your code?

Check out the "Role of NotImplemented" over on pydev.  The script is the last half of the first post.

--
~Ethan~


More information about the Python-ideas mailing list