[Python-ideas] parameter annotation semantics

[Steven D'Aprano]

Bruce Leban wrote:

> On Sat, Apr 16, 2011 at 6:27 PM, Steven D'Aprano <steve at pearwood.info>wrote:
> 
>> Bruce Leban wrote:
>>
>>  One
>>> of the strange aspects (to me) of parameter annotations is that they have
>>> no
>>> semantics which opens them up to multiple conflicting uses.
>>>
>> That's not a bug, that's a feature.
>>
>> It's been stated many times by Guido that it's far too early to standardize
>> on a single meaning for annotations. (We may *never* standardize on a single
>> meaning.) Instead, it is up to the library or decorator to impose whatever
>> meaning makes sense for that particular library or decorator.
> 
> 
> I understand that. I can still think it a bit strange, can't I? To be more
> specific, you hit the crux of the problem with the statement "it is up to *
> THE* library or decorator to impose whatever meaning makes sense" [emphasis
> added] is that it assumes the singular. If I want to use two decorators
> which impose different meanings, I'm stuck. Imagine I have two decorators
> like this:


Well, yes, you're stuck... but if we standardise on a single meaning, 
then you can't have two decorators with different meanings, can you?

This is kind like stating that we should standardise on a single flavour 
of ice cream (vanilla), because otherwise if you want two clashing 
flavours (liquorish and lemon, say) on the same cone, they will clash.

Yes, if you pick two clashing decorators, they will clash. So either 
write a bridge between them, or do without one.

This is hardly unique to annotations. You can't take two arbitrary 
decorators and sensibly combine them either.


@eat_cake_now
@save_cake_for_later
def get_cake():
     pass


Could developers write decorators that process annotations in a 
cooperative fashion, regardless of the nature of the other decorators? 
Perhaps they could, but that will hardly prevent clashes:

@exclude_given_types
@include_given_types
def func(arg: float):
     pass


But even ignoring such obvious clashes, I'm not convinced that such 
cooperative signature processing is desirable. It seems to me that to 
make this work, decorators would have to be written to ignore 
annotations they don't expect, Just In Case some other decorator might 
be expecting them:


@include_given_types
def func(arg: "float"):  # Oops, I meant a type object, not a string.
     pass


This would mask errors and make debugging much harder.


Now, of course this is not to suggest that any particular library can't 
be written in a cooperative fashion. But it seems to me that it would 
have to cooperate with a finite set of other *known* decorators (perhaps 
only its own, perhaps some other well-known library), rather than trying 
to interoperate with arbitrary decorators that expect arbitrary 
signatures and do arbitrary things.





-- 
Steven