On 21 August 2016 at 15:22, Nick Coghlan <ncogh...@gmail.com> wrote: > There may also be a case to be made for introducing an AtomicStr type > into Python's data model that works like a normal string, but > *doesn't* support indexing, slicing, or iteration, and is instead an > opaque blob of data that nevertheless supports all the other usual > string operations. (Similar to the way that types.MappingProxyType > lets you provide a read-only view of an otherwise mutable mapping, and > that collections.KeysView, ValuesView and ItemsView provide different > interfaces for a common underlying mapping)
Huh, prompted by Brendan Barnwell's comment, I just realised that a discussion I was having with Graham Dumpleton at PyCon Australia about getting the wrapt module (or equivalent functionality) into Python 3.7 (not 3.6 just due to the respective timelines) is actually relevant here: given wrapt.ObjectProxy (see http://wrapt.readthedocs.io/en/latest/wrappers.html#object-proxy ) it shouldn't actually be that difficult to write an "atomic_proxy" implementation that wraps arbitrary container objects in a proxy that permits most operations, but actively *prevents* them from being treated as collections.abc.Container instances of any kind. So if folks are looking for a way to resolve the perennial problem of "How do I tell container processing algorithms to treat *this particular container* as an opaque blob?" that arise most often with strings and binary data, I'd highly recommend that as a potentially fruitful avenue to start exploring. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
