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

[Jim Jewett]

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

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

That part is admittedly a guideline for development of python, rather
than with python.  The question is what happens with something like

    def f(a:int): ...

If the thing starts compiling (like Pyrex) to code which assumes an
int and doesn't verify, that would be a disaster waiting to happen --
unless int were explicitly reserved to the python core more strongly
than the proposed wording implies.

> 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))):

mylist_subtype is as unique as an object (but not as a name); if xxx
is sufficient disambiguation, then so is mylist_subtype on its own.

> > 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:

For builtin lists, they meaning should be reserved to python core.
What does the following mean?

    def f(a:[int, str])

I assume it doesn't mean a list of int and str (because lists are used
for independent annotations).  I assume it also doesn't mean "int _or_
str" because the annotations are independent.  If they two are
supposed to be used together, then they should be chained with
something other than list.

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

Agreed.  But I think the PEP should explicitly reserve the
(annotational) meaning of

(1)  builtin and standard library types, such as int and Decimal
(2)  The results of combining types with operators (such as |, +=, etc)
(3)  lists, tuples, and dictionaries of the above

It doesn't have to say what they mean, but it has to warn that a
standard meaning is contemplated, and that 3rd parties should consider
them reserved.

-jJ