[Python-ideas] Proposal: Use mypy syntax for function annotations

[Burak Arslan]

On 08/23/14 04:36, Steven D'Aprano wrote:
> But another reason for disliking call syntax for this is that it gets
> confusing:
>
> def function(param:Sequence(Spam, Eggs))->Mapping(Cheese, Toast):
>
> suffers compared to this:
>
> def function(param:Sequence[Spam, Eggs])->Mapping[Cheese, Toast]:
>
> In the second case, the type annotations stand out more easily because
> they use square brackets instead of round.
>

You're only giving examples with builtins. What about:

    def function(param:SomeClass(Spam, Eggs))->SomeOtherClass(Cheese,
Toast):

If there are template instantiations  (in the C++ sense) there that's
another meaning for parens which already have two meanings. And now
they're also context-dependent!.. At least they were all the same
everywhere before.

So SomeClass[Spam, Eggs] is a fabulous idea -- in my mind it's just a
special way of looking up a certain type.

But as I said before[1] I'd hate to see annotations only be used for type
checking.

I'd love to be able to do:

    Integer[ge=5]

but this comes with the question about what should actually  passed to
__getitem__

I'd avoid changing its signature to accept **kwargs. So I'd say that

    Unicode[15, pattern='[0-9a-z]+']

should translate to:

    {0: 15, 'pattern': '[0-9a-z]+'}

which is a frozen ordered dict. As that's actually a better tuple that
also happens to accept string keys, I doubt that'd interfere with the
existing usage.

We need this for duck typing to work as well. To my understanding, the
type marker "File" means "only accept what's returned by open()". If
however, we want to accept any file-like object, we could use
Object[write=Callable]. Or maybe more specifically:
Object[write=Callable[Bytes]].



> -1 on re-using call syntax: it is more confusing to read inside a
> parameter list, too flexible, and clashes with existing use calling
> types.
>
> +1 on subscripting syntax: it is more easily distinguishable from
> calling, just flexible enough, and doesn't clash with existing
> functionality.
>

Well, we need that flexibility at the very least for making duck typing
work with type-annotated functions.

best,
burak

[1]: https://mail.python.org/pipermail/python-ideas/2014-August/028988.html
[2]: https://github.com/arskom/spyne/pull/313#issuecomment-29029067