[Python-ideas] parameter annotation semantics
steve at pearwood.info
Sun Apr 17 10:10:22 CEST 2011
Bruce Leban wrote:
> On Sat, Apr 16, 2011 at 6:27 PM, Steven D'Aprano <steve at pearwood.info>wrote:
>> Bruce Leban wrote:
>>> of the strange aspects (to me) of parameter annotations is that they have
>>> 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.
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:
def func(arg: float):
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:
def func(arg: "float"): # Oops, I meant a type object, not a string.
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.
More information about the Python-ideas