Expose dictproxy through collections rather than the types module?
The internal dictproxy class was recently exposed as types.MappingProxyType. Since it's not very discoverable that way, would anyone object if I moved things around so it was exposed as collections.MappingProxy instead? The main benefit to doing so is to get it into the table of specialised container types at the top of the collections module docs [1]. [1] http://docs.python.org/dev/library/collections Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Apr 21, 2012 7:11 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
The internal dictproxy class was recently exposed as
types.MappingProxyType.
Since it's not very discoverable that way, would anyone object if I moved things around so it was exposed as collections.MappingProxy instead? The main benefit to doing so is to get it into the table of specialised container types at the top of the collections module docs [1].
A discussion on this played out in http://bugs.python.org/issue14386. -eric
[1] http://docs.python.org/dev/library/collections
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail....
On Sat, 21 Apr 2012 23:09:08 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
Since it's not very discoverable that way, would anyone object if I moved things around so it was exposed as collections.MappingProxy instead? The main benefit to doing so is to get it into the table of specialised container types at the top of the collections module docs
The short answer is yes, someone would mind, which is why it is where it is. Read the ticket for more: http://bugs.python.org/issue14386. --David
On Sun, Apr 22, 2012 at 12:43 AM, R. David Murray <rdmurray@bitdance.com> wrote:
On Sat, 21 Apr 2012 23:09:08 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
Since it's not very discoverable that way, would anyone object if I moved things around so it was exposed as collections.MappingProxy instead? The main benefit to doing so is to get it into the table of specialised container types at the top of the collections module docs
The short answer is yes, someone would mind, which is why it is where it is. Read the ticket for more: http://bugs.python.org/issue14386.
No worries. Someone was asking on python-ideas about creating an immutable ChainMap instance, and I was going to suggest collections.MappingProxy as the answer (for future versions, of course). I was surprised to find it squirrelled away in the types module instead of being somewhere anyone other than a core dev is likely to find it. I personally suspect the lack of demand Raymond describes comes from people just using mutable dicts and treating them as immutable by convention - the same way Python programs may have "immutable by convention" objects which don't actually go to the effort needed to fully prevent mutation of internal state after creation. Some objects would be more correct if they did that, but in practice, it's not worth the hassle to make sure you've implemented it correctly. Still, it doesn't bother me enough for me to try to persuade Raymond its sufficiently valuable to make it public through the collections module. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Eric Snow -
Nick Coghlan -
R. David Murray