Container __get/set/delitem__? (was Re: [Zope3-dev] naming issues: id vs name, delObject vs ?)

[Guido van Rossum]

> Python's "mapping protocol" feels too loose for an interface-driven
> system such as Zope3 to emulate properly:  we should layer the
> interfaces (e.g., as the 'Interface.Common.Mapping' module does, only
> more so).  Containers which permit '__getitem__/get' access to their
> items should not likewise be required to allow 'keys/items/values'
> (*especially 'items/values'!);  likewise, allowing '__setitem__' should
> *not* promise that 'update/clear/etc' are available.

But this doesn't have to mean that you have to forego the Pythonic
spellings.  You can define several Interfaces that define various
aspects of Python's mapping interfaces rigorously.  In particular, you
could have interfaces IReadOnlyMapping and its subclass
IWritableMapping that define exactly which mapping attributes are
implemented.

Also note that keys(), values() and items() of mappings don't have to
return lists or even sequences -- in Python 2.2 and later, they can be
iterators too, and the interface can specify this.

> So, in the end, I would argue that the spelling::
> 
>    for key, item in getAdapter( folderish, IEnumerableMapping ).items():
>        #...
> 
> if far superior to::
> 
>    for key, item in folderish.items():
>        #...
> 
> because it doesn't assume "folder is just like dictionary";  instead, it
> leverages the component architecture, so that an adapter for "expensive"
> containers could be written which "lazified" the 'items' and 'values'
> calls.

Maybe.  If we knew that folderish implemented IReadOnlyMapping and we
knew that IReadOnlyMapping defined items(), the getAdapter() call
wouldn't be necessary.  But at least in either case the actual method
is called items(), and that's progress.

--Guido van Rossum (home page: http://www.python.org/~guido/)