[Python-3000] Abilities / Interfaces

[Guido van Rossum]

On 11/21/06, Robert Brewer <fumanchu at amor.org> wrote:
> Guido van Rossum wrote:
> > But it's not so easy to define which APIs must be present to for
> > verification of a particular interface to pass. A Mapping must
> > implement __getitem__() in a certain way.
> > But does it need to implement __len__?
>
> The Ref Manual seems to think so:
> http://docs.python.org/ref/types.html#l2h-68:
>
> "The subscript notation a[k] selects the item indexed by k from the
> mapping a; this can be used in expressions and as the target of
> assignments or del statements. The built-in function len() returns the
> number of items in a mapping."
>
> > get()? keys()? values() and items()?
>
> http://docs.python.org/ref/sequence-types.html implies all other methods
> are optional (even if heavily encouraged):
>
> "It is also recommended that mappings provide the methods keys(),
> values(), items(), has_key(), get(), clear(), setdefault(), iterkeys(),
> itervalues(), iteritems(), pop(), popitem(), copy(), and update()
> behaving similar to those for Python's standard dictionary objects."
>
> I'd be happy starting with the requirements as stated in the ref
> (__getitem__, __setitem__, __delitem__, and __len__, as I read it), and
> make any additions or other changes to that contract a separate
> discussion. (But then, I'm personally happy with having this API
> specified in the ref and don't see a need to codify it with interfaces.)

For Py3k we certainly have the freedom (not to mention the obligation
:-) to rewrite the reference manual, so this isn't dogma for me.

> > Is it okay for a particular mapping implementation to allow
> > only one iterator to exist  (per instance) at any time,
> > like dbm files do?
>
> Sure, because the current spec doesn't deny it.
>
> If we have to have interfaces, I think we'd be far better off
> implementing the spec as-is first, and worry about changing the spec
> later (even if if only seems to be an "implied spec" at the moment). I
> didn't write the Ref Manual, of course, sir ;) so I can't assert its
> intent unequivocally, but as a consumer of it, I expect "it is
> recommended" to mean "not an interface requirement".

IMO the situation with respect to the current "de-facto" interfaces
and standard types is sufficiently messy that we will be *forced* to
change the spec. In fact I'd be disappointed if some good deep
thinking about the ontology of interfaces wouldn't lead us to some
welcome changes to the specs.

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