[Python-ideas] parameter annotation semantics

Bruce Leban bruce at leapyear.org
Sun Apr 17 06:53:18 CEST 2011


Subject was: Re: [Python-ideas] Simple class initialization



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:

@memoize  # memoizes return values; if memo_value annotation is used,
memoizes using
          # the value returned by applying the function
def a(foo:memo_value(int), bar:memo_value(tuple)):
  pass

@log_me  # logs function calls and return values excluding parameters
annotated no_log
def b(foo, bar:no_log):
  pass


Can I use both @memoize and @logging? Not if they're defined as they are
above. I can if the decorators expect a list of annotations instead of a
solo annotation:

@memoize
def a(foo:[memo_value(int)], bar:[memo_value(tuple)]):
  pass

@log_me
def b(foo, bar:[no_log]):
  pass

@memoize
@log_me
def c(foo:[memo_value(int)], bar:[no_log, memo_value(tuple)]):
  pass


Note that I am NOT proposing a change to the language (none is necessary),
just suggesting that this would be good advice to offer authors. PEP 8
offers no advice on annotation syntax and PEP 3107 explicitly does not offer
any advice saying "Despite yet more discussion, it was decided not to
standardize a mechanism for annotation interoperability."

What I would propose is something more like this:

There is no standard for annotation interoperability. Annotations that wish
to support interoperability should consider treating the annotation as an
enumerable of values and checking value in annotation  (or something
similar) instead of value == annotation.


Of course an obvious alternative is

@memoize
@log_me
def c(foo:{memoize:memo_value(int)}, bar:{log_me:no_log,
memoize:memo_value(tuple)}):
  pass


but I think that's too verbose and therefore less likely to be adopted.

--- Bruce
*New! *Puzzazz newsletter: http://j.mp/puzzazz-news-2011-04 including April
Fools!
*New!** *Blog post: http://www.vroospeak.com Ironically, a glaring Google
grammatical error
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110416/3d097a93/attachment.html>


More information about the Python-ideas mailing list