PEP 484: updates to Python 2.7 signature syntax
PEP 484 was already updated to support signatures as type comments in Python 2.7. I'd like to add two more variations to this spec, both of which have already come up through users. First, https://github.com/python/typing/issues/188. This augments the format of signature type comments to allow (...) instead of an argument list. This is useful to avoid having to write (Any, Any, Any, ..., Any) for a long argument list if you don't care about the argument types but do want to specify the return type. It's already implemented by mypy (and presumably by PyCharm). Example: def gcd(a, b): # type: (...) -> int <code here> Second, https://github.com/python/typing/issues/186. This builds on the previous syntax but deals with the other annoyance of long argument lists, this time in case you *do* care about the types. The proposal is to allow writing the arguments one per line with a type comment on each line. This has been implemented in PyCharm but not yet in mypy. Example: def gcd( a, # type: int b, # type: int ): # type: (...) -> int <code here> In both cases we've considered a few alternatives and ended up agreeing on the best course forward. If you have questions or feedback on either proposal it's probably best to just add a comment to the GitHub tracker issues. A clarification of the status of PEP 484: it was provisionally accepted in May 2015. Having spent close to a year pondering it, and the last several months actively using it at Dropbox, I'm now ready to move with some improvements based on these experiences (and those of others who have started to use it). We already added the basic Python 2.7 compatible syntax (see thread starting at https://mail.python.org/pipermail/python-ideas/2016-January/037704.html), and having used that for a few months the two proposals mentioned above handle a few corner cases that were possible but a bit awkward in our experience. -- --Guido van Rossum (python.org/~guido)
On Mar 19, 2016, at 18:18, Guido van Rossum <guido@python.org> wrote:
Second, https://github.com/python/typing/issues/186. This builds on the previous syntax but deals with the other annoyance of long argument lists, this time in case you *do* care about the types. The proposal is to allow writing the arguments one per line with a type comment on each line. This has been implemented in PyCharm but not yet in mypy. Example:
def gcd( a, # type: int b, # type: int ): # type: (...) -> int <code here>
This is a lot nicer than what you were originally discussing (at #1101? I forget...). Even more so given how trivial it will be to mechanically convert these to annotations if/when you switch an app to pure Python 3. But one thing: in the PEP and the docs, I think it would be better to pick an example with longer parameter names. This example shows that even in the worst case it isn't that bad, but a better example would show that in the typical case it's actually pretty nice. (Also, I don't see why you wouldn't just use the "old" comment form for this example, since it all fits on one line and isn't at all confusing.)
Heh. I could add an example with a long list of parameters with long names, but apart from showing by example what the motivation is it wouldn't really add anything, and it's more to type. :-) On Sat, Mar 19, 2016 at 6:43 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Mar 19, 2016, at 18:18, Guido van Rossum <guido@python.org> wrote:
Second, https://github.com/python/typing/issues/186. This builds on the previous syntax but deals with the other annoyance of long argument lists, this time in case you *do* care about the types. The proposal is to allow writing the arguments one per line with a type comment on each line. This has been implemented in PyCharm but not yet in mypy. Example:
def gcd( a, # type: int b, # type: int ): # type: (...) -> int <code here>
This is a lot nicer than what you were originally discussing (at #1101? I forget...). Even more so given how trivial it will be to mechanically convert these to annotations if/when you switch an app to pure Python 3.
But one thing: in the PEP and the docs, I think it would be better to pick an example with longer parameter names. This example shows that even in the worst case it isn't that bad, but a better example would show that in the typical case it's actually pretty nice. (Also, I don't see why you wouldn't just use the "old" comment form for this example, since it all fits on one line and isn't at all confusing.)
-- --Guido van Rossum (python.org/~guido)
This seemed pretty uncontroversial -- I've updated the PEP (including a long(ish) example :-). On Sat, Mar 19, 2016 at 6:54 PM, Guido van Rossum <guido@python.org> wrote:
Heh. I could add an example with a long list of parameters with long names, but apart from showing by example what the motivation is it wouldn't really add anything, and it's more to type. :-)
On Sat, Mar 19, 2016 at 6:43 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Mar 19, 2016, at 18:18, Guido van Rossum <guido@python.org> wrote:
Second, https://github.com/python/typing/issues/186. This builds on the previous syntax but deals with the other annoyance of long argument lists, this time in case you *do* care about the types. The proposal is to allow writing the arguments one per line with a type comment on each line. This has been implemented in PyCharm but not yet in mypy. Example:
def gcd( a, # type: int b, # type: int ): # type: (...) -> int <code here>
This is a lot nicer than what you were originally discussing (at #1101? I forget...). Even more so given how trivial it will be to mechanically convert these to annotations if/when you switch an app to pure Python 3.
But one thing: in the PEP and the docs, I think it would be better to pick an example with longer parameter names. This example shows that even in the worst case it isn't that bad, but a better example would show that in the typical case it's actually pretty nice. (Also, I don't see why you wouldn't just use the "old" comment form for this example, since it all fits on one line and isn't at all confusing.)
-- --Guido van Rossum (python.org/~guido)
-- --Guido van Rossum (python.org/~guido)
participants (2)
-
Andrew Barnert -
Guido van Rossum