<p dir="ltr"></p>
<p dir="ltr">--<br>
Ryan<br>
[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.<br>
<a href="http://kirbyfan64.github.io/">http://kirbyfan64.github.io/</a><br>
On Mar 18, 2016 5:51 PM, "Rick Johnson" <<a href="mailto:rantingrickjohnson@gmail.com">rantingrickjohnson@gmail.com</a>> wrote:<br>
><br>
><br>
> @Everyone: Okay i'm completely confused as to were we are in<br>
> the "type hints" evolution. It seems to have taken all sorts<br>
> of random twists and turns -- will someone please explain?<br>
><br>
> (see examples below)<br>
><br>
> @Guido: i've skimmed PEP484, and i've read your handful of<br>
> "issues", but i need to know *EXACTLY* what a type hint<br>
> declaration will look like *BEFORE* i can offer my opinion<br>
> on these matters. At this point, i'm not overly concerned<br>
> about the dirty details of how type hints will be<br>
> implemented "under the hood", my first concern is, to<br>
> understand what *onerous* this feature will be placing on<br>
> the programmer, and, what *damage* it will could cause to<br>
> the "general readability" of Python source code. In other<br>
> words -- i need to decide if this is a good idea or not.<br>
><br>
> In pep484, the declaration seems to be firmly<br>
> coupled/interleaved with the source code:<br>
><br>
>     def greeting(name: str) -> str:<br>
>         return 'Hello ' + name<br>
><br>
> Oh my. But if so, i would hardly call this "a hint". Are we<br>
> going to introduce `->` as a method for defining the return<br>
> type of a function, and special-case `:` for binding types<br>
> to symbols in sigs?<br>
></p>
<p dir="ltr">Neither! Python 3 type hints are just function annotations. It's the job of a type checker/linter (like mypy) to actually decipher the annotations as types. Adding/removing type hints won't have a runtime effect on your program.</p>
<p dir="ltr">> But the rabbit hole goes deeper...<br>
><br>
> After reading PEP484, i'm looking over your list of issues,<br>
> and i see you using "magic comments" like this:<br>
><br>
>     def whatever(<br>
>              arg1,  # type: int<br>
>              arg2,  # type: int<br>
>              arg3,  # type: int<br>
>              arg4,  # type: str<br>
>              arg5,  # type: str<br>
>              arg6,  # type: str<br>
>              ):<br>
>         # type: (...) -> float<br>
>         # this is not a type comment (note that "..." above is literal)<br>
>         return (arg1 + arg2 + arg3 +<br>
>                 float(arg4) + float(arg5) + float(arg6))<br>
><br>
> So which is it? The former? The latter? Or both?<br>
></p>
<p dir="ltr">I think the latter is for Python 2.</p>
<p dir="ltr">> PS: As i await your response, I'm praying to the FSM that<br>
> type hints will be implemented as the latter, and *NOT* the<br>
> former. And i'm *SO* fearful of the thought of the former,<br>
> that i'm *literally* shaking as i write this response--<br>
> *PLEASE* tell me it's the latter.<br>
></p>
<p dir="ltr">PEP 484 already was passed using the former syntax...so you might be a little late saying that...</p>
<p dir="ltr">><br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-ideas">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a><br>
</p>