[Python-ideas] PEP 484 evolution

[Ryan Gonzalez]

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Mar 18, 2016 5:51 PM, "Rick Johnson" <rantingrickjohnson at gmail.com>
wrote:
>
>
> @Everyone: Okay i'm completely confused as to were we are in
> the "type hints" evolution. It seems to have taken all sorts
> of random twists and turns -- will someone please explain?
>
> (see examples below)
>
> @Guido: i've skimmed PEP484, and i've read your handful of
> "issues", but i need to know *EXACTLY* what a type hint
> declaration will look like *BEFORE* i can offer my opinion
> on these matters. At this point, i'm not overly concerned
> about the dirty details of how type hints will be
> implemented "under the hood", my first concern is, to
> understand what *onerous* this feature will be placing on
> the programmer, and, what *damage* it will could cause to
> the "general readability" of Python source code. In other
> words -- i need to decide if this is a good idea or not.
>
> In pep484, the declaration seems to be firmly
> coupled/interleaved with the source code:
>
>     def greeting(name: str) -> str:
>         return 'Hello ' + name
>
> Oh my. But if so, i would hardly call this "a hint". Are we
> going to introduce `->` as a method for defining the return
> type of a function, and special-case `:` for binding types
> to symbols in sigs?
>

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.

> But the rabbit hole goes deeper...
>
> After reading PEP484, i'm looking over your list of issues,
> and i see you using "magic comments" like this:
>
>     def whatever(
>              arg1,  # type: int
>              arg2,  # type: int
>              arg3,  # type: int
>              arg4,  # type: str
>              arg5,  # type: str
>              arg6,  # type: str
>              ):
>         # type: (...) -> float
>         # this is not a type comment (note that "..." above is literal)
>         return (arg1 + arg2 + arg3 +
>                 float(arg4) + float(arg5) + float(arg6))
>
> So which is it? The former? The latter? Or both?
>

I think the latter is for Python 2.

> PS: As i await your response, I'm praying to the FSM that
> type hints will be implemented as the latter, and *NOT* the
> former. And i'm *SO* fearful of the thought of the former,
> that i'm *literally* shaking as i write this response--
> *PLEASE* tell me it's the latter.
>

PEP 484 already was passed using the former syntax...so you might be a
little late saying that...

>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160318/0f4c470d/attachment.html>