Python Sanity Proposal: Type Hinting Solution

[Fetchinson .]

On 1/23/15, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> Terry Reedy wrote:
>
>> On 1/22/2015 10:59 PM, Chris Angelico wrote:
>>> On Fri, Jan 23, 2015 at 2:22 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>>> This idea is so brilliant that it is already an option in mypy and is
>>>> part
>>>> of the new type-hint proposal.  The separate type-hint files are called
>>>> 'stub files'.
>>>
>>> It's worth pointing out, too, that the idea isn't panaceaic - it's
>>> just another tool in the box. Any time you break related things into
>>> separate places, especially separate files, the tendency for them to
>>> get out of sync grows dramatically.
>>
>> The same could be said of putting tests in a separate file.
>
> I agree!
>
> Python has doctests, which live right there with the function. It also has
> assertions, which can be considered a form of continuous testing.
>
> Eiffel has syntax for design-by-contract (testing pre-conditions,
> post-conditions and invariants) there in the body of the function or
> method:
>
> https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions#Expressing_assertions
>
>
> Contracts are a form of testing, since they are designed to be disabled in
> production. Other languages with syntactic support for Design By Contract
> include Clojure, Cobra, D, Mercury, Perl6 and Racket.
>
> Cobra is especially close to Python-like syntax, and supports unit tests as
> well:
>
>
>     def sqroot(i as int) as float
>         require
>            i > 0
>         ensure
>            result > 0
>         tests
>            assert sqroot(25) == 5.0
>         body
>             ...
>
> It would be nice to be able to include at least *some* tests right there in
> the code rather than in a separate file.

I completely agree. A cobra-style type hinting implementation would
satisfy everyone who doesn't want to make function signatures noisy
(including me) and would also satisfy those who advocate for the
actual feature (type hinting) without worrying much about the
implementation detail. These two groups are overlapping by the way :)

In any case, I'm pretty sure it was said before, but I can't really
find it anywhere, can someone tell me what the rationale is for
*function signature* type hinting?

I totally get type hinting in general, but why does it have to be in
the function signature? Any reason for that specifically?

Are there lots of folks who actually insist on the type hints being in
the function signature and definitely want to see it there and not
somewhere else?

I'd say cobra-style type hinting would be great, but also something
which is property looking:

@official_type_hinting_by_the_psf( arg1: str, arg2: int, returns: bool )
def myfunction( arg1, arg2 ):
    return True

I really like the idea that in python I don't have lots of choices in
many areas, certain things are dictated. The big advantage is that
when I read other people's code I know what to expect so me being
restricted is a small price to pay that is totally worth it. So I'd
come down on the side of the complainers in this case, the type
hinting pep introduces noisy and not so readable features (I
understand these are optional) which if used will make readability
suffer. If there is a pep for it, people will use it, so the fact that
it is optional is irrelevant, it will be used, so people will be faced
with it when reading other people's code, whether they like it or not.

Cheers,
Daniel




-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown