[Python-ideas] Conventions for function annotations

[Antoine Pitrou]

Le Mon, 3 Dec 2012 00:09:17 -0800,
Raymond Hettinger
<raymond.hettinger at gmail.com> a écrit :
> 
> Early core developer attempts to use function annotations revealed
> inconsistent, ad-hoc annotation styles. For example:
> 
> [str] was ambiguous as to whether it represented a list of strings or
> a value that could be either str or None. The notation
> open(file:(str,bytes)) was used for a value that could be either
> bytes or str rather than a 2-tuple containing a str value followed by
> a bytesvalue. The annotation seek(whence:int) exhibited an mix of
> over-specification and under-specification: int is too restrictive
> (anything with __index__ would be allowed) and it is not restrictive
> enough (only the values 0, 1, and 2 are allowed). Likewise, the
> annotation write(b: bytes) was also too restrictive (anything
> supporting the buffer protocol would be allowed). Annotations such as
> read1(n: int=None) were self-contradictory since None is not an int.
> Annotations such as source_path(self, fullname:str) -> objectwere
> confusing about what the return type should be. In addition to the
> above, annotations were inconsistent in the use of concrete types
> versus abstract types: int versus Integral and set/frozenset versus
> MutableSet/Set. Some annotations in the abstract base classes were
> incorrect specifications. For example, set-to-set operations require
> other to be another instance of Setrather than just an Iterable.

In short, we have discovered that declarative typing isn't very
useful :-)

Regards

Antoine.