[Python-ideas] Conventions for function annotations

[David Townshend]

Just thought of a couple of usages which don't fit into the decorator
model.  The first is using the return annotation for early binding:

    def func(seq) -> dict(sorted=sorted):
        return func.__annotations__['return']['sorted'](seq)

Stangely enough, this seems to run slightly faster than

    def func(seq, sorted=sorted):
        return sorted(seq)

My test shows the first running in about 0.376s and the second in about
0.382s (python 3.3, 64bit).


The second is passing information to base classes.  This is a rather
contrived example which could easily be solved (better) in plenty of other
ways, but it does illustrate a pattern which someone else may be able to
turn into a genuine use case.

class NumberBase:

    def adjust(self, value):
        return self.adjust.__annotations__['return'](value)


class NegativeInteger(NumberBase):

    def adjust(self, value) -> int:
        return super().adjust(-value)


>>> ni = NegativeInteger()
>>> ni.adjust(4.3)
-4


Cheers

David


On Tue, Dec 4, 2012 at 1:02 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> So long as any type hinting semantics are associated with a "@type_hints"
> decorator, none of those ideas conflict with my suggestions for good
> annotation usage practices.
>
> The explicit decorators effectively end up serving as dialect specifiers
> for the annotations, for the benefit of other software (by moving the
> metadata out to purpose specific attributes) and for readers (simply by
> being present).
>
> Anyway, the reactions here confirmed my recollection of a lack of
> consensus amongst the core team. I'll just put something up on my own site,
> instead.
>
> Cheers,
> Nick.
>
> --
> Sent from my phone, thus the relative brevity :)
> On Dec 4, 2012 3:28 AM, "Guido van Rossum" <guido at python.org> wrote:
>
>> Hm. I agree PEP 8 seems an odd place for Nick's recommendation. Even
>> if I were to agree with hos proposal I would think it belongs in a
>> different PEP than PEP 8.
>>
>> But personally I haven't given up on using annotations to give type
>> hints -- I think it can at some times be a useful augmentation to
>> static analysis (whose use I see mostly as an aid to human readers
>> and/or tools like linters, IDEs, and refactoring tools, not for
>> guiding compiler optimizations). I know of several projects (both
>> public and private) for improving the state of the art of Python
>> static analysis with this goal in mind. With the advent of e.g.
>> TypeScript and Dart in the JavaScript world, optional type annotations
>> for dynamic languages appear to be becoming more fashionable, and
>> maybe we can get some use out of them.
>>
>> FWIW, as far as e.g. 'int' being both overspecified and
>> underspecified: I don't care about the underspecification so much,
>> that's always going to happen; and for the overspecification, we can
>> either use some abstract class instead, or simply state that the
>> occurrence of certain concrete types must be taken as a shorthand for
>> a specific abstract type. This could be part of the registration call
>> of the concrete type, or something.
>>
>> Obviously this would require inventing and standardizing notations for
>> things like "list of X", "tuple with items X, Y, Z", "either X or Y",
>> and so on, as well as a standard way of combining annotations intended
>> for different tools.
>>
>> *This* would be a useful discussion. What to do in the interim... I
>> think the current language in PEP 8 is just fine until we have a
>> better story.
>>
>> --Guido
>>
>> On Mon, Dec 3, 2012 at 7:34 AM, Barry Warsaw <barry at python.org> wrote:
>> > On Dec 03, 2012, at 09:08 PM, Nick Coghlan wrote:
>> >
>> >>I would be *quite delighted* if people are open to the idea of making a
>> >>much stronger recommendation along the following lines explicit in PEP
>> 8:
>> >
>> > I am -1 for putting any of what followed in PEP 8, and in fact, I think
>> the
>> > existing examples at the bottom of PEP 8 are inappropriate.
>> >
>> > PEP 8 should be prescriptive of explicit Python coding styles.  Think
>> "do
>> > this, not that".  It should be as minimal as possible, and in general
>> provide
>> > rules that can be easily referenced and perhaps automated (e.g.
>> pep8.py).
>> >
>> > Some of the existing text in PEP 8 already doesn't fall under that
>> rubric, but
>> > it's close enough (e.g. designing for inheritance).
>> >
>> > I don't think annotations reach the level of consensus or practical
>> experience
>> > needed to be added to PEP 8.
>> >
>> > OTOH, I wouldn't oppose a new informational PEP labeled "Annotations
>> Best
>> > Practices", where some of these principles can be laid out and explored.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121204/f4a54239/attachment.html>