[Python-ideas] Proposal: Use mypy syntax for function annotations

[Guido van Rossum]

On Thu, Aug 14, 2014 at 8:51 PM, Andrew Barnert <
abarnert at yahoo.com.dmarc.invalid> wrote:

>
> Most of the code in typing.py is a duplication of the ABCs in the
> collections.abc module (and io and maybe others). I understand that MyPy
> couldn't monkeypatch that code into the stdlib, so it had to fork the
> contents, but if this is going into the stdlib, can't we just modify
> collections/abc.py instead? Why not have the type information on
> collections.abc.Sequence be introspectable at runtime? More importantly,
> why not have the interface defined by collections.abc.Sequence be _exactly_
> the same as the one checked by the static type checker, instead of just
> very similar?
>
> This would also make it easier for some libraries to document their types.
> For example, dbm.* could inherit from or register with
> MutableMapping[bytes, bytes] instead of just MutableMapping, and then it
> wouldn't have to explain in the docstring that the keys and values have to
> be bytes.
>
> Once you move the ABC typing to the actual ABCs, the only problem left is
> the built-in (concrete) collections. But I still don't understand why
> people even _want_ those to be checked. Does anyone have a good example of
> a function that needs to restrict its arguments to list[str] instead of
> Sequence[str]? Guido gave us a _terrible_ example: a function whose most
> obvious use was on text files, but he added a static type check that
> prevents it being used that way. And I think that will be the case the vast
> majority of the time. When I see documentation in a PyPI library or a
> colleague's code that says a function takes a list, it's almost always a
> lie; the function in fact takes any iterable (or occasionally any sequence
> or mutable sequence). (In fact, every exception I can think of is written
> in C, so it couldn't be easily annotated anyway.) It seems like we're
> making things a lot harder for ourselves, just for a handful of types that
> people are almost
>  always going to use wrong.
>
> (As a side note, generic ABCs might even be the answer to the AnyStr
> problem: str implements String[str], bytes implements String[bytes],
> bytearray implements MutableString[bytes], and classes like PyObjC's
> NSString can now document that they implement String[str] or String[bytes]
> as appropriate.)
>
> Anyway, these leaves typing.py as nothing but functions (Union, Optional,
> etc.) on types defined elsewhere, in the rest of the stdlib.
>

I think I already responded to a similar proposal. I think modifying the
existing ABCs is fine for Python 3.5 and beyond, but I think I'd like to
keep aliasing in the typing module to make it easier to use annotations in
earlier Python versions (using a typing.py installed from PyPI).

I feel similar about using a|b as a concise way to spell Union[a, n], and
int|None would be quite decent as a way to spell optional int. But again,
these could only be used in code meant exclusively for Python 3.5 and later.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140814/8e809879/attachment.html>