Add Symmetric Difference Operators To Dict

Ideas
22

About the use cases - you are probably right, it is just a bit disappointing that for adding a simple and pretty straight forward feature so much effort is required.

About “what we expected to happen when using the ^ operation” - here you are wrong. PEP 584 already did the decision - to be consistent with it the symmetric difference need to be by the keys only and not the key-value pair. The other ideas you brought up were discussed in PEP 584

23

Yes, and the response you got is “that’s not sufficient - you need to demonstrate that there’s a real world need for this operation”. You haven’t yet done that.

Unfortunately, your opinion isn’t what matters here. This is a requirement that every proposal for a change to Python has to satisfy, and there’s no reason your proposal should be exempt. If this gets added, books will need updating, training materials will need to be modified, tools (such as linters) will need to review how they handle the new operator, etc., etc. The cost of any change to Python is significant these days, and has to be balanced by clearly demonstrable benefits. It’s (unfortunately, you could say) one of the downsides of being one of the most popular programming languages in the world - every change affects millions of people.

That’s far from certain. As I say, you’ll be making books and training materials obsolete, triggering changes to linters, autoformatters, IDEs, etc, and probably plenty of other changes. What you’re dismissing as “no harm” will in practice be extra work for many developers, most of whom will be volunteers and will get no compensation for their work.

1 Like
24

Thanks for your time and detailed answer (@pf_moore, @MegaIng), I understand the importance of testing the use cases before such a change.
Here is such example from a quick lookup:
numpy/distutils/ccompiler_opt.py
Before:

            feature.update({
                k:v for k,v in cfeature.items() if k not in feature
            })

After:

            feature ^= cfeature

Interesting note: during the searches I got an interesting insight regarding a similar feature - the - operator - implementing this operator for dictionaries has tons of open source uses that will make the code simpler and more readable.

Therefore I want to propose adding the - and -= operations for dicts in python:
d1 - d2 = {k:v for k,v in d1.items() if k not in d2}
This operation will be extremely useful, and the largest amount of examples I saw to it is when the rightmost parameter is a dict or a set.
I think that this operation can come to good use also when the second parameter is a set (it is debatable if we should include every possible collection), in the other hand it will make the feature proposal less concise.

Use cases I saw in large open source projects

matplotlib/axes/_axes.py
Before:

        return self.plot(
            *args, **{k: v for k, v in kwargs.items() if k not in d})

After:

        return self.plot(*args, **(kwargs - d))

sqlalchemy/cyextension/collections.pyx
Before:

        else:
            other = {cy_id(obj): obj for obj in iterable}
        result._members = {k: v for k, v in self._members.items() if k not in other}

After:

        else:
            other = {cy_id(obj): obj for obj in iterable}
        result._members = self._members - other

setuptools/dist.py
Before:

        metadata_only = set(self._DISTUTILS_UNSUPPORTED_METADATA)
        metadata_only -= {"install_requires", "extras_require"}
        dist_attrs = {k: v for k, v in attrs.items() if k not in metadata_only}

After:

        metadata_only = set(self._DISTUTILS_UNSUPPORTED_METADATA)
        metadata_only -= {"install_requires", "extras_require"}
        dist_attrs = attrs - metadata_only

TO SUM UP

  1. The ^ proposed operation has use cases where it will make the code more readable, it is a natural extension of PEP 584, but indeed less useful from the | operation (it is similar to how the ^ in sets is less useful than the other set operations).
  2. The - operation for dicts is extremely useful and I believe almost every python developer used a “long” dict comprehension instead of it in the past.
  3. It is debatable if the operations should be implemented also to enable mixing the dict and set types. For example dict1 - set1 should be a dictionary and set1 - dict1 should be a set.
  4. In order to be concise, in my opinion it is better that in the current proposal we do not include the implementation of mixing a dictionary and another type in the same operation.
  5. Since it seems that the subtraction operation is more useful, it may be worth issuing a PEP for it before the symmetric difference operation, or implement them together in the same PEP.
  6. What do you say guys? Is there a python core developer in the audience who wants to go with me on the journey to implement the idea?
25

How exactly is this a compatible change? If cfeature contains keys already in feature, they are now getting deleted instead of keeping the value they have in feature. I would strongly recommend you get more careful with your proposed changes and actually fully think them through.

And with you now suggesting - also as a viable candidate I am going to direct you to: Dictionaries should have key-based set operations

There have been many such proposals, but most of the fizzle out, and I am not really sure why. But I wouldn’t focus on ^, - seems like a better candidate, for that there are quite a few usecases.

1 Like
26

After looking at some open-source code it seems that there are little to no use cases of this new d1 ^ d2 that I am proposing, in some of the replies below I got confused about it, so maybe this feature should wait for the future.

During my wanderings through the code of popular packages I saw lots of potential use cases for the - operator and the -= operators, I want to add this feature in a PEP and I am looking for a sponsor - Add Difference Operators To Dict

If this is a good idea in your opinion, I would love for you to be my sponsor for such a PEP :slight_smile: