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

Tres Seaver tseaver@zope.com
15 May 2002 11:06:28 -0400


On Wed, 2002-05-15 at 10:28, Guido van Rossum wrote:
> > 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.
>=20
> 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.
>=20
> 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.
>=20
> > So, in the end, I would argue that the spelling::
> >=20
> >    for key, item in getAdapter( folderish, IEnumerableMapping ).items()=
:
> >        #...
> >=20
> > if far superior to::
> >=20
> >    for key, item in folderish.items():
> >        #...
> >=20
> > because it doesn't assume "folder is just like dictionary";  instead, i=
t
> > leverages the component architecture, so that an adapter for "expensive=
"
> > containers could be written which "lazified" the 'items' and 'values'
> > calls.
>=20
> 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.

The 'getAdapter' call is required for the kinds of "polymorphic" cases
people were arguing for earlier;  the only code which could forego it
would be very tightly bound to those assumptions.  I don't actually
object to the Pythonic spellings, only to the notion that people should
be encouraged to use them without doing the lookup first, because the
lookup is the "safety belt" against naivet=E9.

Tres.
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com