Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <54c339d7$0$13005$c3e8da3$5496439d@news.astraweb.com>
References: <6da1eb58-a0bb-4d37-8293-0a8cafe6a89c@googlegroups.com> <m9sep8$p53$1@ger.gmane.org> <CAPTjJmqXLWEkz-KzxWWD4KRkHs4cdC3Z0DKZ8otjqTkytydsmQ@mail.gmail.com> <mailman.18018.1421989508.18130.python-list@python.org> <54c1e349$0$12975$c3e8da3$5496439d@news.astraweb.com> <mailman.18034.1422019400.18130.python-list@python.org> <54c339d7$0$13005$c3e8da3$5496439d@news.astraweb.com>
Date: Sat, 24 Jan 2015 22:01:16 +0100
Subject: Re: Python Sanity Proposal: Type Hinting Solution
From: "Fetchinson ." <fetchinson@googlemail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18098.1422133285.18130.python-list@python.org>
Lines: 158
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:84491

On 1/24/15, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Fetchinson . wrote:
>
>> On 1/23/15, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> [...]
>>> 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 :)
>
> I don't understand this. Cobra's type-hints are right there in the function
> signature, just like Python annotations.
>
>
> # Cobra
> def sqroot(i as int) as float
>
> # Python
> def sqroot(i:int)->float:

You are right. This aspect is pretty close, what I had in mind, but
expressed myself poorly is this idiom in cobra:

def myfunc( a, b )
    require
        something_about( a, b )
    ensure
        something_about_the_return_value

Yes, type hinting and arbitrary constraints on the function arguments
and return types are different things, but closely related. I'd say it
makes sense to combine the two.

>
> Cobra's use of "as" clashes with Python. In Python, "as" is used for
> name-binding:
>
> import module as name
> with open('file') as f
> except Exception as e
>
> but apart from that minor difference, they're virtually identical.
>
>
>> 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?
>
> The basic principle is that things which are related should be found
> together. The further away they are, the worse.
>
> Bad:
> - the parameter name and the type are in different files
>
> Better:
> - the parameter name and the type are only a few lines apart
>
> Best:
> - the parameter name and type are right next to each other
>
>
> The closer they are, the easier it is to keep them in sync, and the easier
> it is to see the relevant information at a glance. Putting them together
> also means that you don't have to repeat the argument name:
>
> int n
> def spam(n): ...
>
> versus
>
> def spam(n:int): ...
>
>
> Those reasons are why decorators have the syntax which they do:
>
> @decorator
> def spam(n):
>     do_this()
>     do_that()
>     do_something_else()
>
>
> is better than the old way of using decorators:
>
> def spam(n):
>     do_this()
>     do_that()
>     do_something_else()
>
> spam = decorator(spam)
>
>
> The decorator is only a single line away from the signature, and you don't
> have to repeat the name.
>
>
> We can see this at work in Pascal. Pascal functions have type declarations
> in the signature, and variable declarations between the signature and the
> body:
>
>
> function sqroot(arg: Integer): Real;
>   var
>     x: Integer;
>     y: Real;
>     z: Something_Else;
>   begin
>     do_this(1, 2);
>     do_that(3, 4);
>     do_something_else(5, 6);
>     x := some expression;  { what's the type of x again? }
>   end;
>
>
> The declarations in the signature work very well and are easy to use, but
> the "var" section, not so much. Especially in large functions, the place
> where you declare the variable and its type, and the place where you first
> use it, can be separated by many lines. This makes maintenance and reading
> of the code more difficult.
>
> Newer languages like Java let you declare the variable the first time you
> use it:
>
>     int x = some expression;
>
> and you don't have to search very far to find out what sort of thing x is,
> it is right there.
>
>
>
> --
> Steven
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown