[Python-3000] Fwd: Conventions for annotation consumers

[Nick Coghlan]

Paul Prescod wrote:
> Given that that's the case, I guess I 
> don't understand the virtue of bringing decorators into the picture. 
> Yes, they are one consumer of metadata. Module-scoped functions are 
> another. Application scoped functions are another. Third party data 
> extraction programs are another. Decorators working with metadata are 
> just special cases of runtime processors of it.

The reason I believe decorators are relevant is because the question that has 
caused this discussion to go on for so long is one of *disambiguation*. That 
is, there are *lots* of different reasons for annotating a function signature, 
so how does a progammer indicate which particular interpretation is the one 
they mean? Obviously, you can say, "I'm using the signature annotations in my 
module for purpose X". However, a later maintainer of your module may go "but 
I wanted to use those annotations for purpose Y!".

Without function signature annotations in the syntax, *this is not a problem*. 
The One Obvious Way to implement both purpose X and purpose Y is as decorator 
factories that accept as arguments the information corresponding to each of 
the function parameters. Multiple decorators can already be stacked on a 
single function, and the names of the different decorators allow the different 
uses to be easily distinguished using the full power of Python's variable 
namespaces.

If signature annotations are added to the language, however, you have a new 
way of doing things: put the information in the signature annotations and 
write a decorator that consumes the signature information. And if two 
different utilities do that, then you have a conflict, and have to invent a 
mechanism for resolving it. And this disambiguation has to happen for each 
individual signature annotation instead of being done once for the whole 
function as would be the case with using separate decorators.

So, as far as I can see, adding signature annotations doesn't let us do 
anything that can't already be done with less ambiguity using decorator 
factories that accept the appropriate arguments.

Samuele's idea of "signature expressions" (i.e. a literal or builtin function 
for producing objects that describe a function's signature) seems like a 
*much* more fruitful avenue for exploration, as it would provide a genuine 
increase in expressiveness (decorator factories would be able to accept a 
single signature argument instead of separate arguments that then need to be 
mapped to the relevant function parameter).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org