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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
