Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 10:10:07 -0700, Devin Jeanpierre wrote: > On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray > wrote: > > IMO, preventing someone from shooting themselves in the foot by modifying > > something they shouldn't modify according to the API is not a Python > > use case ("consentin

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread Devin Jeanpierre
On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray wrote: > IMO, preventing someone from shooting themselves in the foot by modifying > something they shouldn't modify according to the API is not a Python > use case ("consenting adults"). Then why have immutable objects at all? Why do you have to p

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread dw+python-dev
On Wed, Jul 16, 2014 at 09:47:59AM -0400, R. David Murray wrote: > It would be nice to be able to return a frozendict instead of having the > overhead of building a new dict on each call. There already is an in-between available both to Python and C: PyDictProxy_New() / types.MappingProxyType. It

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread Eric Snow
On Wed, Jul 16, 2014 at 7:47 AM, R. David Murray wrote: > After I hit send on my previous message, I thought more about your > example. One of the issues here is that modifying the dict breaks an > invariant of the API. I have a similar situation in the email module, > and I used the same soluti

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 14:04:29 -, dw+python-...@hmmz.org wrote: > On Wed, Jul 16, 2014 at 09:47:59AM -0400, R. David Murray wrote: > > > It would be nice to be able to return a frozendict instead of having the > > overhead of building a new dict on each call. > > There already is an in-between

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 03:27:23 +0100, MRAB wrote: > >>> # Try modifying the pattern object. > ... p.groupindex['JUNK'] = 'foobar' > >>> > >>> # What are the named groups now? > ... p.groupindex > {'first': 1, 'second': 2, 'JUNK': 'foobar'} > >>> > >>> # And the match object? > ... m.groupdict()

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 03:27:23 +0100, MRAB wrote: > Here's another use-case. > > Using the 're' module: > > >>> import re > >>> # Make a regex. > ... p = re.compile(r'(?P\w+)\s+(?P\w+)') > >>> > >>> # What are the named groups? > ... p.groupindex > {'first': 1, 'second': 2} > >>> > >>> # Per

Re: [Python-Dev] Another case for frozendict

2014-07-15 Thread MRAB
On 2014-07-16 00:48, Russell E. Owen wrote: In article , Chris Angelico wrote: On Mon, Jul 14, 2014 at 12:04 AM, Jason R. Coombs wrote: > I can achieve what I need by constructing a set on the ‘items’ of the dict. > set(tuple(doc.items()) for doc in res) > > {(('n', 1), ('err', No

Re: [Python-Dev] Another case for frozendict

2014-07-15 Thread Russell E. Owen
In article , Chris Angelico wrote: > On Mon, Jul 14, 2014 at 12:04 AM, Jason R. Coombs wrote: > > I can achieve what I need by constructing a set on the ‘items’ of the > > dict. > > > set(tuple(doc.items()) for doc in res) > > > > {(('n', 1), ('err', None), ('ok', 1.0))} > > This is

Re: [Python-Dev] Another case for frozendict

2014-07-13 Thread Nick Coghlan
On 13 July 2014 13:43, wrote: > In its previous form, the PEP seemed more focused on some false > optimization capabilities of a read-only type, rather than as here, the > far more interesting hashability properties. It might warrant a fresh > PEP to more thoroughly investigate this angle. RIght

Re: [Python-Dev] Another case for frozendict

2014-07-13 Thread dw+python-dev
On Sun, Jul 13, 2014 at 06:43:28PM +, dw+python-...@hmmz.org wrote: > if d: > d = d.copy() To cope with iterables, "d = d.copy()" should have read "d = dict(d)". David ___ Python-Dev mailing list Python-Dev@python.org h

Re: [Python-Dev] Another case for frozendict

2014-07-13 Thread dw+python-dev
On Sun, Jul 13, 2014 at 02:04:17PM +, Jason R. Coombs wrote: > PEP-416 mentions a MappingProxyType, but that’s no help. Well, it kindof is. By combining MappingProxyType and UserDict the desired effect can be achieved concisely: import collections import types class frozendict(c

Re: [Python-Dev] Another case for frozendict

2014-07-13 Thread Mark Roberts
I find it handy to use named tuple as my database mapping type. It allows you to perform this behavior seamlessly. -Mark > On Jul 13, 2014, at 7:04, "Jason R. Coombs" wrote: > > I repeatedly run into situations where a frozendict would be useful, and > every time I do, I go searching and fin

Re: [Python-Dev] Another case for frozendict

2014-07-13 Thread Chris Angelico
On Mon, Jul 14, 2014 at 12:04 AM, Jason R. Coombs wrote: > I can achieve what I need by constructing a set on the ‘items’ of the dict. > set(tuple(doc.items()) for doc in res) > > {(('n', 1), ('err', None), ('ok', 1.0))} This is flawed; the tuple-of-tuples depends on iteration order, which m

Re: [Python-Dev] Another case for frozendict

2014-07-13 Thread Victor Stinner
The PEP has been rejected, but the MappingProxyType is now public: $ ./python Python 3.5.0a0 (default:5af54ed3af02, Jul 12 2014, 03:13:04) >>> d={1:2} >>> import types >>> d = types.MappingProxyType(d) >>> d mappingproxy({1: 2}) >>> d[1] 2 >>> d[1] = 3 Traceback (most recent call last): File "",

[Python-Dev] Another case for frozendict

2014-07-13 Thread Jason R. Coombs
I repeatedly run into situations where a frozendict would be useful, and every time I do, I go searching and find the (unfortunately rejected) PEP-416. I'd just like to share another case where having a frozendict in the stdlib would be useful to me. I was interacting with a database and had a