On Apr 16, 2020, at 07:19, Soni L. <fakedme...@gmail.com> wrote:
>
> what about a dict.setdefaults (note the s) that takes in an iterable or a
> dict, and uses insert-or-ignore behaviour? (unfortunately a lot of iterables
> and all generators are hashable, and we can't break that.)
>
> I could really use something like that tbh.
Then tell us the use cases that you have in mind.
I can think of lots of common uses for “override this dict with that one”, such
as the typical “defaults, config file, environment, argv” thing that most
command line tools do. But I can already write that, in idiomatic and readable
code (and in fact with variations—update, |, or ChainMap); why would I want to
be able to write the same thing in another way that’s conceptually backward,
probably less efficient, and doesn’t work in Python 3.8? If the issue is just
that you have those default values in a list of pairs rather than a dict, it’s
trivial to just construct a dict from that.
Maybe there are good use cases where the usual way would feel backward or wrong
and setdefaults would be nicer. But if so, you need to show some.
And they have to be pretty common. You can obviously already write that as `for
k, v in defaults: d.setdefault(k, v)`, which is acceptable if it comes up once
a year, but demands improvement if people are (or should be, if they only
realized it) writing it all over the place.
(If the API were obviously symmetrical, the bar might be a lot lower. See the
Haskell dict update operators—I’ll bet I’ve often used the “backward” ones and
not even realized it, because they don’t look backward or unusual, and because
Haskell in general encourages that kind of symmetrical thinking everywhere, to
the extent that even “pass this arg to that function” is almost as commonplace
as “call this function with that arg”. But I don’t think Python could get there
from here, even if it were a good idea.)
More generally, it seems like you think Python needs to include everything
anyone can think of that might theoretically be useful somewhere. But it’s
designed to only include (almost) everything people need regularly and can’t
just trivially and build for themselves, because aiming for that sweet spot
keeps Python discoverable and Python code readable—and similarly for Rust,
Swift, Ruby, and other languages that attempt to go that way, even if none of
them (including Python) pulls it off perfectly. A kitchen sink language is even
worse than a no-batteries-included language—it isn’t just harder to design and
implement, it’s harder to use. You have more docs to wade through to find
anything, more subtle distinctions to think through to decide, more stuff to
remember when you come back to the language after time spent doing other stuff,
more trouble reading code written by other people who internalized a different
subset of the kitchen sink, etc.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/LIEVKGZHN3PD5DGDQIZTE6TWRTCL6KIK/
Code of Conduct: http://python.org/psf/codeofconduct/
