[Python-ideas] Conventions for function annotations

[Guido van Rossum]

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)