[Python-3000] PEP: Information Attributes (original) (raw)

Jim Jewett jimjjewett at gmail.com
Tue May 1 17🔞52 CEST 2007

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

More information about the Python-3000 mailing list