|
|
Log in / Subscribe / Register

Re: Adding "+" and "+=" operators to dict

From:  Donald Stufft <donald-/z0sg0XqlqBhl2p70BpVqQ-AT-public.gmane.org>
To:  Paul Moore <p.f.moore-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org>
Subject:  Re: Adding "+" and "+=" operators to dict
Date:  Thu, 12 Feb 2015 14:27:38 -0500
Message-ID:  <868B43AF-2144-47DD-A2C2-45C6920A714A@stufft.io>
Cc:  Python-Ideas <python-ideas-+ZN9ApsXKcEdnm+yROfE0A-AT-public.gmane.org>


> On Feb 12, 2015, at 2:14 PM, Paul Moore <p.f.moore-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 
> On 12 February 2015 at 18:43, Steven D'Aprano <steve-iDnA/YwAAsAk+I/owrrOrA@public.gmane.org>
wrote:
>> I'm going to quote Raymond Hettinger, from a recent discussion here:
>> 
>> [quote]
>> I wouldn't read too much in the point score on the StackOverflow
>> question.  First, the question is very old [...] Second, StackOverflow
>> tends to award high scores to the simplest questions and answers [...] A
>> high score indicates interest but not a need to change the language. A
>> much better indicator would be the frequent appearance of ordered sets
>> in real-world code or high download statistics from PyPI or
>> ActiveState's ASPN cookbook.
>> [end quote]
> 
> I'm surprised that this hasn't been mentioned yet in this thread, but
> why not create a function, put it on PyPI and collect usage stats from
> your users? If they are high enough, a case is made. If no-one
> downloads it because writing your own is easier than adding a
> dependency, that probably applies to adding it to the core as well
> (the "new dependency" then would be not supporting Python <3.5 (or
> whatever)). Converting a 3rd party function to a method on the dict
> class isn't particularly hard, so I'm not inclined to buy the idea
> that people won't use it *purely* because it's a function rather than
> a method, which is the only thing a 3rd party package can't do.
> 
> I don't think it's a good use for an operator (neither + nor | seem
> particularly obvious fits to me, the set union analogy
> notwithstanding).

Honestly I don’t think "put it on PyPI" is a very useful thing in cases like
these. Consuming a dependency from PyPI has a cost, such the same as dropping
support for some version of Python has a cost. For something with an easy
enough work around the cost is unlikely to be low enough for people to be
willing to pay it.

Python often gets little improvements that on their own are not major
enhancements but when looked at cumulatively they add up to a nicer to use
language. An example would be set literals, set(["a", "b"]) wasn't confusing
nor was it particularly hard to use, however being able to type {"a", "b"} is
nice, slightly easier, and just makes the language jsut a little bit better.

Similarly doing:

    new_dict = dict1.copy()
    new_dict.update(dict2)

Isn't confusing or particularly hard to use, however being able to type that
as new_dict = dict1 + dict2 is more succinct, cleaner, and just a little bit
nicer. It adds another small reason why, taken with the other small reasons,
someone might want to drop an older version of Python for a newer version.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


to post comments


Copyright © 2015, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds