[Python-3000] Draft pre-PEP: function annotations (original) (raw)

Jim Jewett jimjjewett at gmail.com
Mon Aug 14 21:11:00 CEST 2006

On 8/13/06, Paul Prescod <paul at prescod.net> wrote:

My proposed text for the PEP is as follows:

Mostly good. A few remaining comments...

Should annotation objects with defined semantics have some standard way to indicate this? (By analogy, new exceptions should inherit from Exception; should annotation objects inherit from an Annotation class, at least as a mixin?)

"This implies that the interpretation of built-in types would be controlled by Python's developers and documented in Python's documentation.

It also implies that the interpretation of annotations made with a built-in type should be safe -- they shouldn't trigger any irreversible actions.

"In Python 3000, semantics will be attached to the following types: objects of type string (or subtype of string) are to be used for documentation (though they are not necessarily the exclusive source of documentation about the type). Objects of type list (or subtype of list) are to be used for attaching multiple independent annotations."

subtypes should be available for other frameworks.

This implies that something other than lists should be used if the annotations are not independent. The obvious candidates are tuples and dicts, but this should be explicit (or explicitly not defined).

The definition of a type as an annotation should probably be either defined or explicitly undefined. Earlier discussions talked about things like

def f (a:int, b:(float | Decimal), c:[int, str, X]) ->str)

This implied that a type object would represent the type of the argument (but would it be safe to call as an adapter?), that special syntactic support might be added for type unions, and that the "independent" part of the list specification should probably be repeated at least in an example. I'm not sure if these implications should be true, but they're obvious enough to some people (and not to others) that the decision should be explicit.

-jJ

More information about the Python-3000 mailing list