On 2 September 2016 at 18:17, Guido van Rossum <guido at python.org> wrote: > On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote: > > On 2 September 2016 at 04:38, Nick Coghlan <ncoghlan at gmail.com> wrote: > >> However, a standalone Ellipsis doesn't currently have a meaning as a > >> type annotation (it's only meaningful when subscripting Tuple and > >> Callable), so a spelling like this might work: > >> > >> NAME: ... > >> > >> That spelling could then also be used in function definitions to say > >> "infer the return type from the return statements rather than assuming > >> Any" > > > > Interesting idea. > > This is somehow similar to one of the existing use of Ellipsis: in numpy it > > infers how many dimensions needs to have the full slice, it is like saying > > "You know what I mean". So I am +1 on this solution. > > I like it too, but I think it's better to leave any firm promises > about the *semantics* of variable annotations out of the PEP. I just > spoke to someone who noted that the PEP is likely to evoke an outsize > emotional response. (Similar to what happened with PEP 484.) > > Pinning down the semantics is not why I am pushing for PEP 526 -- I > only want to pin down the *syntax* to the point where we won't have to > change it again for many versions, since it's much harder to change > the syntax than it is to change the behavior of type checkers (which > have fewer backwards compatibility constraints, a faster release > cycle, and narrower user bases than core Python itself). This is a good point. I totally agree. -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160902/3a099d16/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4