[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