[Python-3000] PEP: Information Attributes

[Jim Jewett]

On 5/1/07, Raymond Hettinger <python at rcn.com> wrote:
> Use Cases with Ambiguous Interpretations

> * The presence of a __getitem__ method is ambiguous in that it can be
>   interpreted as either having sequence or mapping behavior.  The ambiguity is
>   easily resolved with an attribute claiming either mapping behavior or
>   sequence behavior.

If you're really duck-typing, it doesn't matter; just try the key and
see if it works.  At this level, Sequences *are* mappings which happen
to have (exactly the) integers from 0 to size-1 as keys.

Knowing that the keys are integers won't tell you whether you can push and pop.

The advantage of the ABC variant is that you do know you can push and
pop, because if the object itself didn't provide an implementation,
then python will fall back to the (abstract class' concrete) default
implementation for you.

> * The presence of a rich comparison operator such as __lt__ is ambiguous in that
>   it can return a vector or a scalar, the scalar may or may not be boolean,
>   and it may be a NotImplemented instance.  Even the boolean case is ambigouus
>   because __lt__ may imply a total ordering (as it does for numbers) or it may
>   be a partial ordering (as it is for sets where __lt__ means a strict
>   subset). That latter ambiguity (sortability) is easily resolved by an
>   attribute indicating a total ordering.

erm... sortability with respect to what?  Only instances of its own
class?  With other string-like things?

> * Some methods such as set.__add__ are too restrictive in that they preclude
>   interaction with non-sets.  This makes it impossible to achieve set
>   interoperability without subclassing from set (a choice which introduces
>   other complications such as the inability to override set-to-set
>   interactions).  This situation is easily resolved by an attribute like
>   obj.__fake__=set which indicates that the object intends to be a set proxy.

How does this improve on registering the object with the abstract Set
class?  If anything, it seems worse, because you need to be able to
modify obj.  ( Josiah suggests a lookaside dictionary -- but that
might as well *be* the ABC.)

> * The __iter__ method doesn't tell you whether the object supports
>   multiple iteration (such as with files) or single iteration (such as with lists).
>   A __singleiterator__ attribute would clear-up the ambiguity.

This seems backwards.  I hope that was just a typo, but *I* can't be
as sure from a single name as I could from a docstringed class.

> * While you can test for the presence of a write() method, it would be
>    helpful to have a __readonly__ information attribute for file-like objects,
>    cursors, immutables, and whatnot.

readonly meaning that I can't modify it, or readonly  meaning that no
one else will?

> The attribute approach is dynamic (doesn't require inheritance to work). It
> doesn't require mucking with isinstance() or other existing mechanisms.

I think a Traits version of ABCs could do that as well, and will try
to get an example coded in the next week or so.

> It restricts itself to making a limited, useful set of assertions rather than
> broadly covering a whole API. It leaves the proven pythonic notion of
> duck-typing as the rule rather than the exception. It resists the temptation
> to freeze all of the key APIs in concrete.

I feel almost the opposite.  Because the attribute is right there on
the object (instead of in a registry I have to import), it is more
tempting to use it; I expect this will cause many more people will
code defensively by adding extra asserts, so that it becomes more
important to support.  Because the object itself is only a single
namespace, it effectively freezes the API that goes out first.

Josiah wrote:
> ... suspect ... weak key dictionaries adding
> traits to classes, and only allow hashable instances for single-object

(I assumed the key would be id(obj), though it would still need a
weakref for data integrity.)

jJ