[Python-3000] iostack and Oh Oh (original) (raw)

Guido van Rossum guido at python.org
Wed Dec 6 21:58:23 CET 2006

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/)

More information about the Python-3000 mailing list