[Python-3000] iostack and Oh Oh

[Guido van Rossum]

On 12/5/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote:
> >My point is that an interface can *document* (at least in English) a
> >"contract" about the invariants between operations. While I'm not into
> >enforcing or verifying such contracts, I'm very interested in
> >documenting them. For example, something that has "mapping" behavior
> >has a very different relationship between x[y] and "y in x" than
> >something that has "sequence" behavior.
>
> I assumed this didn't need answering.  If you're using the interface solely
> for documentation, then a namespace-oriented interface suffices to provide it.

I don't follow. I feel awfully stupid right now -- I have a major
roadblock to understanding how your proposal helps my use case and you
think that it doesn't even need answering. Maybe I should just give up
and accept that I'll never understand your proposal; it can be
reconsidered for Python 4000 by a future BDFL.

> >  If you see interfaces as
> >*just* combinations of operations there is no way to put this
> >information.
>
> Ah.  I've been thinking of this as there being two different 'getitem'
> operations, like at the C level.

But having two operations at the C level is actually a major problem
-- considering e.g. that lists currently implement "mapping-getitem"
just so they can handle extended slices. AFAIK it's generally accepted
that it was a mistake to have separate C operations, and this is
slated to be fixed in Py3k.

Anyway I don't think it is right to claim that there are many
different operations if the normal way of spelling them is overloaded.
I see these overloaded operations as *the same* operation (a GF as you
say) but with different semantics (and sometimes a different return
type) based on what category of object it is (e.g. mapping, sequence
or set).

The "mapping" example you claim caused so much trouble due to
different understanding of what it means to be a mapping can IMO be
addressed quite well by adopting a hierarchy of mapping ABCs as
sketched in Bill J's wiki page. A lot of the problems in the example
(and probably in Zope's interfaces) are caused by the non-existence of
a *standard* set of ABCs that people can use to model their classes.
Thus users make do with vague notions such as "file-like" and
"mapping" that encourage Humpty Dumptyism, and don't even distinguish
between the most basic variants, like mutability (in terms of required
API, not in terms of actual capabilities of the object) or
iterability.

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