On Mon, May 06, 2019 at 08:10:44PM +0300, Serge Matveenko wrote:
> On Sun, May 5, 2019 at 1:08 PM Luca Baldini wrote:
> >
> > Hi here,
> > I wonder if the idea of adding to the statistics module a class to
> > calculate the running statistics (average and standard deviation) of a
> > generic input
Frankly, I don't think an "as dict" protocol is worth it, but if others did
think so, we could:
define a new dunder: __as_mapping__
(I'm using "mapping", rather than "dict", to allow duck typing)
Then the built-in dict() constructor would:
check for an __as_mapping__ dunder:
-- if there, it
>
> 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_mappin
>
> > It would still require other types to add and maintain __mapping__
> dunders.
Sure — but that is inherent in this whole idea — nothing other than the
type object itself could possibly know how to dictify itself.
Though yeah, that’s the key question— how often is this useful???
-CHB
--
Ch
>
> Sure — but that is inherent in this whole idea — nothing other than the
> type object itself could possibly know how to dictify itself.
>
This seems to have an obvious solution: object.__as_mapping__() could
simply call dict(self). Anything that uses the mapping protocol could then
be mappifie
