Expose a child factory using MappingProxyType in builtins
We have the immutable frozenset for sets and and tuples for lists. But we also have something to manipulate dict as immutable datastructures:
We could expose this as a built type to allow the last of the most important data structure in Python to be easily immutable.
Searching MappingProxyType on GitHub gives over 10,000 results. I think it probably makes sense to make mappingproxy more "visible", maybe move it to collections module? (where OrderedDict lives) I am not sure if it makes sense to move it to builtins. (for comparison frozenset gives around 1000,000 results) -- Ivan On 28 February 2017 at 16:24, Joseph Hackman <josephhackman@gmail.com> wrote:
The difference in hits might be because MappingProxyType has a funny name and is in a hidden-ish location. I.e. not necessarily because it *would be* less used or useful if it were more exposed. In either case, the name that makes sense to me would be `frozendict`. That could very well live in `collections` of course. On Tue, Feb 28, 2017 at 7:40 AM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
I've implemented `frozendict` a few times for various projects and never knew about MappingProxyType. I always used `collections.abc.Mapping` ... On Tue, Feb 28, 2017 at 9:12 AM, David Mertz <mertz@gnosis.cx> wrote:
It also might be because you can use `frozenset` in python2.x code -- And there's lots of that lying around...
In either case, the name that makes sense to me would be `frozendict`. That could very well live in `collections` of course.
Yes, I agree. Though it'd also probably need to be hashable if we were to give it that name. I'm not 100% sure that `MappingProxyType` works there as it's just a view into another mapping. If the first mapping changes, so does the hash. This is the same problem we have hashing tuple in some sense -- But tuple can say "Nope, sorry. I can't hash this because it's got an unhashable member". I don't think we can really do the same thing with a MappingProxy since most of the time, it'll be constructed from something else. I suppose the workaround is pretty simple though: class frozendict(MappingProxyType): def __init__(self, proxy): super().__init__(proxy.copy()) # Copy the proxy! -- Maybe need `copy.copy()` instead? def __hash__(self): return hash(frozenset(self.items())) This could likely be done better, but hopefully it gets the idea across...
-- [image: pattern-sig.png] Matt Gilson // SOFTWARE ENGINEER E: matt@getpattern.com // P: 603.892.7736 We’re looking for beta testers. Go here <https://www.getpattern.com/meetpattern> to sign up!
I would be very happy to see a frozendict in collections :) Just for curiosity ; apart caching, is there any optimization that can be done on a frozendict implementation (over dict) ? I wonder if frozendict would be implemented as dict without modification methods, or as a particular object that by design does not easily allow modifications. On 28/02/2017 21:05, Matt Gilson wrote:
2017-02-28 13:17 GMT+01:00 Michel Desmoulin <desmoulinmichel@gmail.com>:
Hello, Such builtin type exists! It's called types.MappingProxyType! ... Sorry, I don't understand your proposition. Do you want to not have to write "from types import MappingProxyType" and put a new type in __builtins__? If yes, I don't think that it's worth it, it's not that hard to add an import to each file using such type. By the way, try to not abuse this type please ;-) (Don't try to put it everywhere?) Victor
On 28 February 2017 at 23:19, Victor Stinner <victor.stinner@gmail.com> wrote:
My interpretation of the idea is to reconsider https://www.python.org/dev/peps/pep-0416/ but put frozendict in collections, not in builtins. MappingProxyType could be a possible implementation (plus copying in constructor and hashing, as proposed above by Matt), but not necessarily. -- Ivan
Searching MappingProxyType on GitHub gives over 10,000 results. I think it probably makes sense to make mappingproxy more "visible", maybe move it to collections module? (where OrderedDict lives) I am not sure if it makes sense to move it to builtins. (for comparison frozenset gives around 1000,000 results) -- Ivan On 28 February 2017 at 16:24, Joseph Hackman <josephhackman@gmail.com> wrote:
The difference in hits might be because MappingProxyType has a funny name and is in a hidden-ish location. I.e. not necessarily because it *would be* less used or useful if it were more exposed. In either case, the name that makes sense to me would be `frozendict`. That could very well live in `collections` of course. On Tue, Feb 28, 2017 at 7:40 AM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
I've implemented `frozendict` a few times for various projects and never knew about MappingProxyType. I always used `collections.abc.Mapping` ... On Tue, Feb 28, 2017 at 9:12 AM, David Mertz <mertz@gnosis.cx> wrote:
It also might be because you can use `frozenset` in python2.x code -- And there's lots of that lying around...
In either case, the name that makes sense to me would be `frozendict`. That could very well live in `collections` of course.
Yes, I agree. Though it'd also probably need to be hashable if we were to give it that name. I'm not 100% sure that `MappingProxyType` works there as it's just a view into another mapping. If the first mapping changes, so does the hash. This is the same problem we have hashing tuple in some sense -- But tuple can say "Nope, sorry. I can't hash this because it's got an unhashable member". I don't think we can really do the same thing with a MappingProxy since most of the time, it'll be constructed from something else. I suppose the workaround is pretty simple though: class frozendict(MappingProxyType): def __init__(self, proxy): super().__init__(proxy.copy()) # Copy the proxy! -- Maybe need `copy.copy()` instead? def __hash__(self): return hash(frozenset(self.items())) This could likely be done better, but hopefully it gets the idea across...
-- [image: pattern-sig.png] Matt Gilson // SOFTWARE ENGINEER E: matt@getpattern.com // P: 603.892.7736 We’re looking for beta testers. Go here <https://www.getpattern.com/meetpattern> to sign up!
I would be very happy to see a frozendict in collections :) Just for curiosity ; apart caching, is there any optimization that can be done on a frozendict implementation (over dict) ? I wonder if frozendict would be implemented as dict without modification methods, or as a particular object that by design does not easily allow modifications. On 28/02/2017 21:05, Matt Gilson wrote:
2017-02-28 13:17 GMT+01:00 Michel Desmoulin <desmoulinmichel@gmail.com>:
Hello, Such builtin type exists! It's called types.MappingProxyType! ... Sorry, I don't understand your proposition. Do you want to not have to write "from types import MappingProxyType" and put a new type in __builtins__? If yes, I don't think that it's worth it, it's not that hard to add an import to each file using such type. By the way, try to not abuse this type please ;-) (Don't try to put it everywhere?) Victor
On 28 February 2017 at 23:19, Victor Stinner <victor.stinner@gmail.com> wrote:
My interpretation of the idea is to reconsider https://www.python.org/dev/peps/pep-0416/ but put frozendict in collections, not in builtins. MappingProxyType could be a possible implementation (plus copying in constructor and hashing, as proposed above by Matt), but not necessarily. -- Ivan
participants (7)
-
David Mertz -
Ivan Levkivskyi -
Joseph Hackman -
lucas -
Matt Gilson -
Michel Desmoulin -
Victor Stinner