[Python-3000] Draft pre-PEP: function annotations

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