[Python-ideas] PEP 484 (Type Hints) -- first draft round

[Guido van Rossum]

On Fri, Jan 16, 2015 at 1:08 PM, Petr Viktorin <encukou at gmail.com> wrote:

> "On Fri, Jan 16, 2015 at 6:17 PM, Guido van Rossum <guido at python.org>
> wrote:
> [...]
> > * Tuple, used as ``Tuple[index0_type, index1_type, ...]``.
> >   Arbitrary-length tuples might be expressed using ellipsis, in which
> >   case the following arguments are considered the same type as the last
> >   defined type on the tuple.
>
> How would Tuple[...] or Tuple[t1, ..., t2] work? The PEP should say
> such shenanigans are undefined, rather than leave it to
> interpretation.
>

Good point. This needs to be elaborated. See
https://github.com/ambv/typehinting/issues/30. (Wanna submit a pull
request?)


> Also, does the empty tuple match Tuple[int, ...]?
>

I think it probably does. At least the corresponding thing for lists works
in mypy:

    x = []  # type: List[int]

So I think we should allow a similar thing for tuples:

    x = ()  # type: Tuple[int, ...]


> [...]
> > * WINDOWS
> >
> > * UNIXOID, equivalent to ``not WINDOWS``
>
> I wonder what the use cases are here. Is this useful, as a dichotomy,
> outside of asyncio (or other low-level stdlib code)?
>

The stdlib is full of things that work differently on Windows. Consequently
application code will also often contain things like

    if <windows>:
        <do it the Windows way>
    else:
        <do it the other way>

Typically each branch can only be type-checked if the stdlib for that
particular platform is accessible. So it makes sense to standardize on a
way of spelling the test in a way that static checkers can understand.

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