>
> dict(myobj) is only defined for mapping objects. For everything else,
> "dict-making" *isn't* addressed.
>
> (Also, it's not a protocol. I think what you want is a protocol, but
> you aren't specifying it well enough for me to grasp.)
Here I was talking about the "mapping protocol" (define keys() and
getitem()) but as you say, this essentially turns your object INTO a
mapping. That isn't the same as some dict-making API (well I guess, unless
you include returning two-tuples from iter). That was bad phrasing on my
part.
> If all you want
is to add dataclasses and namedtuples to the list of things dict() copes
> with, that's entirely reasonable. If you have a list of obviously
> mapping-like things dict() should cope with, that's fine. If you want
> someone else to go do the work for you, that's less fine, but hey,
> someone might think it's an interesting thing to do. If you want dict()
> to cope with arbitrary objects (which you still appear to), you need to
> say how.
>
At this point I am really exploring the problem and potential solutions.
Your responses have been helpful.
I do not have a list of obviously mapping-like things that eschew the
mapping protocol, other than NT and dclses. It would be helpful to know if
more of these exist. I'd be happy to try and look for them, but I don't
really know how I'd do that.
You bring up a good point-- dict() likely makes more sense for this than
expanding the dataclasses.asdict(). Looking at your menu of choices (which
I think hit on most of the potential solutions), I would change my initial
approach to the problem and suggest instead that two ideas should be
considered:
- add NamedTuple._asdict() and dataclasses.asdict() to the list of
things dict() copes with
- add an alt constructor that behaves just like the dict() constructor,
but "dicts harder", as you put it
But I see two problems with doing it using the dict() constructor:
- typing.NamedTuple and @dataclass classes can also define their own
keys() and getitem()-- the behavior of which might diverge from their
respective asdict() methods. So dict() would need to decide whether
nt._asdict() and dataclasses.asdict() take precedence over the mapping
protocol (I would suggest that IF the mapping protocol exists on an object,
it would take precedence).
- I am sure there is lots of code out there currently depending on
errors occuring when dict() is applied to a NT.
So of the two options, I think an alt constructor is far superior. The alt
constructor would still need to decide the first precedence problem though.
I am minded of the Larson cartoon, "...and now a miracle occurs..."
> This is the first time you've mentioned this argument (to dict(),
> presumably?).
I would actually be hesitant to use an API that just said "oh, throw
anything at me, I'll cope."
Well my initial idea (now reconsidered) was to change the behavior of
dataclasses.asdict(), which does already have a dict_factory kwarg. I was
referring to that asdict() argument. However for me, adding a kwarg to
dict() is not on the table; dict() makes use of **kwargs and reserving one
for this purpose is surely a bad idea.
That last comment makes sense to me, but the alternative- adding handling
of NT and dclses to dict()- seems bad because of backward compatibility
problem I mentioned above.
Therefore because of the constructor **kwargs problem, and because I agree
miracles are bad things in programming :), and because you are right that
it is better for the user to present the data in an expected format,
adopting a dict_factory kwarg is probably not worth bothering with. I'm to
happy to abandon that.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
