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

[Jim Baker]

(My apologies in advance that I have not been able to read all the emails
on this set of threads.)

Mypy’s approach to parameterizing types using slice notation/__getitem__ is
a rather neat hack, given how it does not require any new notation, matches
rather similar syntax in languages like Scala and Haskell, and can be
readily added to existing types, whether builtins like list, collections
like deque, or ABC collection types like Iterator andSequence. Adding such
parameterization support to builtin/stdlib types is a compelling reason for
including in 3.5. An enthusiastic +1!

Such support is also a very good reason for Jython 3.x to target 3.5.

However, let's not restrict Python’s support for static typing, or related
schemes like gradual typing, to just what Mypy can do now. This should be
about a preferred syntax, especially since there’s other active work, some
of which I’m involved in like Reticulated (
http://wphomes.soic.indiana.edu/jsiek/), which has the possibility of
helping with such issues as better Java integration in Jython, such as with
the Clamp project (https://github.com/jimbaker/clamped).

Instead, I like what one message stated - that such type expressions in
function annotations can be arbitrarily complicated expressions. We can
have simple parameterization, but also disjunctive types, and more. In
certain simple cases, linters will be able to meaningfully work with such
type expressions without having to evaluate the defining module (if not
actually run it); in other cases, they won’t. But this is just what linters
cope with now. We see something similar in Clamp, since we need to evaluate
class definitions ahead-of-time to generate the bytecode for corresponding
Java proxy classes - otherwise, we would not have a jar that Java/JVM code
could use for linkage.

Using type variables is another aspect that can be addressed in this
proposed syntax, but it is readily doable without further modification.
Consider a type expression like Sequence[T] - the only thing that we need
to do is assign the type variable T in the scope of the annotation usage.
I’m pretty certain we can do some pretty nice things with such type
variable assignments to describe type bounds, variance, and what not, for
those so inclined and type checkers that can handle. Again, this keeps
things nicely open without undue restrictions.

One last thing: let’s not add List, TList, etc. Just use list and other
existing types to generate new types. I think this is the main reason why
3.5 support is needed. Being able to use types as objects in this fashion
is a wonderful pleasure of working with Python as of new style classes (so
I will assume now that we are talking about Python 3.5!). The same goes for
putting such support in docstrings (although static type checkers could
potentially attempt to cross validate) and in comments. Using stub files in
contrast is a great idea, and something that can also be standardized on.

Thanks again for a fantastic, if somewhat overwhelming conversation.

- Jim


On Wed, Aug 20, 2014 at 7:42 PM, Stephen J. Turnbull <stephen at xemacs.org>
wrote:

> Terry Reedy writes:
>
>  > If the annotation for a library are in a separate skeleton file
>
> You mean stub file, right?  (Stub is the term used so far in this
> thread.)
>
> To develop Terry's idea a bit more explicitly, ISTM that during early
> development, you use Python 3 with annotations in file.  Then when you
> need to test Python 2, you use a tool (as yet to be developed) which
> generates a Python file that has had all annotations stripped, and a
> stub file[1].  Throw away the stub file, test the Python file, and
> return to development.
>
> For distribution (to *both* Python 3 and Python 2 users) you ignore
> the original annotated code and distribute the generated Python file
> and the stubs file.  Probably there would be a tool for combining the
> Python and stub files back into an annotated Python file.
>
> The two tools (stripper and annotator) can be very accurate (although
> the annotator may not produce precisely the style desired by users,
> the tools probably can be designed so that the re-annotated file
> accurately reflects the style used by the authors).
>
> Is the implied workflow really so burdensome?  Especially to
> downstream?
>
> Note that Terry works on IDLE, so it seems likely that at least one
> Python IDE would support this workflow very well. :-)
>
> Footnotes:
> [1]  Yes, I know, the stub file is actually Python, too.  You know
> what I mean.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
- Jim

jim.baker@{colorado.edu|python.org|rackspace.com|zyasoft.com}
twitter.com/jimbaker
github.com/jimbaker
bitbucket.com/jimbaker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140820/3913174e/attachment-0001.html>