[Python-ideas] add an additional dataclasses.asdict option for non-dataclasses

[Rhodri James]

On 10/05/2019 21:22, Ricky Teachey wrote:
>>
>> As far as I can see, the only downside of this is that it would means a
>> new standard dunder, which is a substantial downside, as (I think) it
>> essentially adds overhead in all sorts of places, plus ads "One more
>> protocol" to a language already ripe with protocols.
>>
> 
> I like the __as_mapping__ idea a lot since it leaves it up to the user to
> determine how dict() does dict-making. But I understand how the overhead
> from adding a single function call could be very significant to something
> that is used as often as dict().

I come back to the point of what the use cases for this are.  So far you 
have presented a situation in which you have made your life difficult in 
order to make other people's lives easier (though I'd contend it doesn't 
actually do that).  If this is a common enough occurrence, that would 
justify adding the (relatively small and self-contained) functionality 
to dict().  I personally doubt it, but I'm ready to be proved wrong.

> What about pairing a __mapping__ method with a mapping() function instead?
> mapping() would not need to be a keyword; it might make sense as part of,
> perhaps, the types library.
> 
> types.mapping() would be significantly slower than dict() only sometimes--
> and resource critical code could still rely on dict(). But it would also be
> more forgiving. And possibly even more useful (for the reasons I've tried
> to do a good job of outlining).

It would still require other types to add and maintain __mapping__ 
dunders.  While the bar for this is lower than adding functionality to 
dict(), I'm still not sure you've got over it.

-- 
Rhodri James *-* Kynesim Ltd