[Python-3000] Questions on optional type annotations
Guido van Rossum
guido at python.org
Thu May 11 20:27:52 CEST 2006
On 5/11/06, Talin <talin at acm.org> wrote:
> Some of the other open issues with signatures are as follows:
>
> o How to use the signature to be able to predict which input arguments
> are going to map against which formal parameters.
Well, there's supposed to be an algorithm defined by the language
spec. There should be an implementation of this algorithm available at
run time. I don't understand your problem here (unless it's about what
that algorithm should be, which I thought we'd hashed out elsewhere?).
> o How to specify constraints (other than types) that are inspectable.
> In other words, a constraint on a parameter shouldn't just be a yes/no
> function, because you can't inspect the function externally and see what
> it means.
>
> If signatures are going to be used to implement rule-based dispatch, the
> dispatcher will be able to run more efficiently if it can decompose the
> signature into individual tests, and combine similar tests from
> different alternative methods, as well as re-ordering the tests so that
> the range of possible results is narrowed quickly. But this only works
> if the tests are more than simple black boxes.
>
> (In other words, don't use lambda as a parameter constraint - but what
> to use instead?)
I'd like to leave this undefined in the PEP. The signature should
simply provide access to the value of the expression (if any) computed
at function definition time from the annotation slot for the
parameter. So if I choose to write
def foo(a: 42 = "blah", b: "hello" + " world" = None) -> range(3): ...
then accessing the annotation for the first parameter should give me
42, for the second parameter should give me "hello world", and for the
return value should give me [0, 1, 2]. What I do with that is my
business.
> o How to specify multiple constraints for a parameter.
That's up to the framework designer who interprets the parameter
annotations. For type-based annotations I've previously proposed the
'|' and '&' operators -- '|' to indicate union types, '&' to indicate
multiple types that must all be satisified. You can use (...) for
grouping, too.
> o How to specify signature constraints that test the signatures of the
> input arguments.
Collin Winter is thinking about this I believe.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list