[Python-3000] Questions on optional type annotations

[Talin]

Nick Coghlan wrote:
> Talin wrote:
> 
>> I haven't forgotten that you asked me to write up a PEP for a 
>> signature API in conjunction with the keyword arguments PEP. However, 
>> I don't yet feel that the ideas have gelled enough to do so yet -- or 
>> at least, I don't feel competent to come up with a definative solution.
> 
> The first draft doesn't have to be definitive :)

Old bad habits die hard :(

> However, being able to create a signature object independently of a def 
> statement is definitely something that should be in there - we'll need 
> it for annotating C methods anyway, so it may make sense to start with 
> that, and then look at making it an integral part of the function header 
> afterwards.

Right. Ideally, I'd like C methods to be able to construct signatures 
out of static data.

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.

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

o   How to specify multiple constraints for a parameter.

o   How to specify signature constraints that test the signatures of the 
input arguments.

-- Talin