A few questions about strictness

[JelleZijlstra]

These are a few things I know exist in some existing stubs. Should we completely prohibit them, or do something else?

• Non-empty function bodies with raise statements. I think this is intended to mean "this function may raise exception X", but I don't know of any type checker that uses this information.
• Default values that are not .... I know pytype chokes on some complicated defaults like bytes literals. Perhaps we should mandate that all default values are ..., or allow only simple values like None, True, False, and integers.
• Placement of # type: ignore. We've encountered mypy-pytype incompatibilities here in the past. I think # type: ignore should be valid on every line.

[srittau]

My thoughts:

• I personally like the idea that a type checker could potentially use this information to check raised exceptions. That said, as long as no type checker has implemented something like it, I don't think we should include it. It can always be added later.
• For consistency's sake and ease of implementation, I would prefer to mandate .... typeshed's CONTRIBUTING also does. If a type checker supports type inference in stubs, that's good on them, but stub author's shouldn't rely on that.
• Sounds reasonable to me.

[rchen152]

• I think we should prohibit non-empty function bodies. If we follow the idea in Are type checkers free to deviate? #6 to allow conformant type checkers to support extra constructs, then any type checker is free to experiment with exception information in private stubs anyway, so it makes sense to me to not introduce it to cross-type checker ones unless/until it's proven useful.
• I like mandating ...; I don't see what value including the actual defaults provides.
• Pardon my ignorance, but what do # type: ignore comments do in a type stub? Allowing them on every line doesn't seem like a particularly onerous requirement for type checkers, but I'm unclear on what type information they convey. (Pytype's parser throws them away.)

[JelleZijlstra]

The use for # type: ignore is that it's useful to use a type checker to test your stubs for validity, even if errors in them get suppressed for users (#9). For example, typeshed runs mypy and pytype to test its stubs. I think the most common cause of # type: ignores in typeshed is subclass methods that are incompatible with their parent types, which mypy gives an error for.

[Solumin]

I also like the idea of having function bodies that provide extra information for type checkers to use. Functions can already be annotated with NoReturn, but that's only half the picture -- listing with exceptions may be raised completes it.

For ..., do you mean mandating it for default values (keyword arguments and variables/fields) and also for function bodies? I support both, though mandating it for function bodies conflates with allowing extra information in function bodies. I suppose that discussion also falls under #6.
At the very least, I would mandate ... for default values.

I'm not sure about # type: ignore. I agree with rche152 that it doesn't seem too onerous to allow them on every line.

[srittau]

I would that that for now we mandate that conforming stubs must use ... for function bodies. That allows experimentation with more information (like exceptions) in bodies, but ensure that current stubs will still be valid, even if during the experimentation the semantics change.

I'd prefer not to put "wishlist" items in the PEP, just currently supported things. The PEP can always be amended later!