[Python-ideas] Conventions for function annotations

[Nick Coghlan]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121204/6ab17712/attachment.html>