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

[Paul Prescod]

On 8/14/06, Jim Jewett <jimjjewett at gmail.com> wrote:
>
> 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?)


All annotation objects have defined semantics (somewhere) or else they are
useless. I don't see any benefit in making them inherit from anything in
particular. Python has a very specific reason for requiring that in the
exception case. I'd rather not complicate the design without a good reason.

> "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.


I disagree and don't think you can come up with a clear definition of
"irreversible" in any case. Is spitting out text to a stream "irreversible"?
I'd rather not complicate stuff.

>  "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.


I'd be happy to remove the whole subtype clause. I don't care much either
way. But anyhow I (now) disagree that there is a problem as stated. If a
framework wants to use a subtype of list they just need to wrap it in a
top-level wrapper that makes the association.

def foo(a: xxx(mylist_subtype(a, b, c))):

This is clear thanks to Collin Winters' recent post.

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 "dependence" between notations is totally up to the framework. To repeat
the example:

def foo(a: xxx(mylist_subtype(a, b, c))):

xxx might say that a is passed as a ".next" attribute to b which is passed
as a ".next" attribute to "c". Or xxx might say that "a" is passed to "b"'s
constructor which is passed to "c"'s constructor. Remeber that "xxx" is
executable so it could do whatever it wants. It should just document what it
did so that various libraries know how to navigate the object structure it
creates.

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)


I think that's a separate (large!) PEP. This PEP should disallow frameworks
from inventing their own meaning for this syntax (requiring them to at least
wrap). Then Guido and crew can dig into this issue on their own schedule.

 Paul Prescod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060814/1629696c/attachment.html