Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #84297 > unrolled thread

Python Sanity Proposal: Type Hinting Solution

Back to article view | Back to comp.lang.python

Contents

  Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 17:15 -0800
    Re: Python Sanity Proposal: Type Hinting Solution MRAB <python@mrabarnett.plus.com> - 2015-01-23 03:22 +0000
    Re: Python Sanity Proposal: Type Hinting Solution Terry Reedy <tjreedy@udel.edu> - 2015-01-22 22:22 -0500
      Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 11:23 -0800
        Re: Python Sanity Proposal: Type Hinting Solution Christian Gollwitzer <auriocus@gmx.de> - 2015-01-24 22:14 +0100
    Re: Python Sanity Proposal: Type Hinting Solution Rustom Mody <rustompmody@gmail.com> - 2015-01-22 19:23 -0800
      Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 11:36 -0800
    Re: Python Sanity Proposal: Type Hinting Solution Chris Angelico <rosuav@gmail.com> - 2015-01-23 14:59 +1100
      Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 11:48 -0800
        Re: Python Sanity Proposal: Type Hinting Solution Chris Angelico <rosuav@gmail.com> - 2015-01-24 06:59 +1100
          Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 12:59 -0800
        Re: Python Sanity Proposal: Type Hinting Solution Mario Figueiredo <marfig@gmail.com> - 2015-01-23 22:02 +0100
          Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 13:59 -0800
            Re: Python Sanity Proposal: Type Hinting Solution Mario Figueiredo <marfig@gmail.com> - 2015-01-23 23:42 +0100
              Re: Python Sanity Proposal: Type Hinting Solution Mario Figueiredo <marfig@gmail.com> - 2015-01-23 23:45 +0100
                Re: Python Sanity Proposal: Type Hinting Solution sohcahtoa82@gmail.com - 2015-01-23 14:52 -0800
                  Re: Python Sanity Proposal: Type Hinting Solution Mario Figueiredo <marfig@gmail.com> - 2015-01-24 00:14 +0100
                Re: Python Sanity Proposal: Type Hinting Solution Marko Rauhamaa <marko@pacujo.net> - 2015-01-24 01:52 +0200
                  Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 16:29 +1100
                    Re: Python Sanity Proposal: Type Hinting Solution Chris Angelico <rosuav@gmail.com> - 2015-01-24 16:38 +1100
                      Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 17:36 +1100
                        Re: Python Sanity Proposal: Type Hinting Solution Chris Angelico <rosuav@gmail.com> - 2015-01-24 17:47 +1100
                    Re: Python Sanity Proposal: Type Hinting Solution Marko Rauhamaa <marko@pacujo.net> - 2015-01-24 11:27 +0200
              Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 15:39 -0800
              Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 00:29 +1100
                Re: Python Sanity Proposal: Type Hinting Solution Mario Figueiredo <marfig@gmail.com> - 2015-01-24 15:09 +0100
                  Re: Python Sanity Proposal: Type Hinting Solution Mario Figueiredo <marfig@gmail.com> - 2015-01-24 15:32 +0100
                  Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 03:05 +1100
                  Re: Python Sanity Proposal: Type Hinting Solution Marco Buttu <marco.buttu@gmail.com> - 2015-01-24 15:25 +0100
                Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-24 08:41 -0800
                  Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 04:26 +1100
                    Re: Python Sanity Proposal: Type Hinting Solution Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-24 17:36 +0000
                    Re: Python Sanity Proposal: Type Hinting Solution Paul Rubin <no.email@nospam.invalid> - 2015-01-24 09:37 -0800
                      Re: Python Sanity Proposal: Type Hinting Solution Chris Angelico <rosuav@gmail.com> - 2015-01-25 06:59 +1100
    Re: Python Sanity Proposal: Type Hinting Solution Terry Reedy <tjreedy@udel.edu> - 2015-01-23 00:03 -0500
      Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 16:59 +1100
        Re: Python Sanity Proposal: Type Hinting Solution "Fetchinson ." <fetchinson@googlemail.com> - 2015-01-23 14:23 +0100
          Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 12:21 -0800
            Re: Python Sanity Proposal: Type Hinting Solution Mario Figueiredo <marfig@gmail.com> - 2015-01-23 22:12 +0100
              Re: Python Sanity Proposal: Type Hinting Solution Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 14:26 -0800
          Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 17:21 +1100
            Re: Python Sanity Proposal: Type Hinting Solution Tim Chase <python.list@tim.thechases.com> - 2015-01-24 06:47 -0600
              Re: Python Sanity Proposal: Type Hinting Solution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 00:40 +1100
                Re: Python Sanity Proposal: Type Hinting Solution Roy Smith <roy@panix.com> - 2015-01-24 09:06 -0500
            Re: Python Sanity Proposal: Type Hinting Solution "Fetchinson ." <fetchinson@googlemail.com> - 2015-01-24 22:01 +0100
        Re: Python Sanity Proposal: Type Hinting Solution Chris Angelico <rosuav@gmail.com> - 2015-01-24 04:11 +1100
        Re: Python Sanity Proposal: Type Hinting Solution "Fetchinson ." <fetchinson@googlemail.com> - 2015-01-23 22:07 +0100
    Re: Python Sanity Proposal: Type Hinting Solution Chris Angelico <rosuav@gmail.com> - 2015-01-23 16:31 +1100

Page 3 of 3 — ← Prev page 1 2 [3]

#84440

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:


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

[toc] | [prev] | [next] | [standalone]

#84462

On 2015-01-24 17:21, Steven D'Aprano wrote:
> # Cobra
> def sqroot(i as int) as float
> 
> # Python
> def sqroot(i:int)->float:
> 
> 
> 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.

Though given that

 def sqrt(i as int) as float:

is invalid Python syntax (both in the parameter list and as the
return value of the function), the meaning of "as" could be overloaded
in both senses to allow for the Cobra-like syntax.

-tkc

[toc] | [prev] | [next] | [standalone]

#84464

Tim Chase wrote:

> On 2015-01-24 17:21, Steven D'Aprano wrote:
>> # Cobra
>> def sqroot(i as int) as float
>> 
>> # Python
>> def sqroot(i:int)->float:
>> 
>> 
>> 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.
> 
> Though given that
> 
>  def sqrt(i as int) as float:
> 
> is invalid Python syntax (both in the parameter list and as the
> return value of the function), the meaning of "as" could be overloaded
> in both senses to allow for the Cobra-like syntax.

OF course it could. But it shouldn't, because "as" already has an
established and consistent meaning: it is used for name binding.

Things which look similar should be similar. "i as int" and "module as name"
look similar, but they are the same syntax for different concepts. "foo as
bar" will sometimes mean that bar is the name bound to foo, and sometimes
it will mean that foo is declared to be type bar. That's messy and
inconsistent and best avoided.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#84465

In article <54c3a0c1$0$13013$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Tim Chase wrote:
> 
> > On 2015-01-24 17:21, Steven D'Aprano wrote:
> >> # Cobra
> >> def sqroot(i as int) as float
> >> 
> >> # Python
> >> def sqroot(i:int)->float:
> >> 
> >> 
> >> 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.
> > 
> > Though given that
> > 
> >  def sqrt(i as int) as float:
> > 
> > is invalid Python syntax (both in the parameter list and as the
> > return value of the function), the meaning of "as" could be overloaded
> > in both senses to allow for the Cobra-like syntax.
> 
> OF course it could. But it shouldn't, because "as" already has an
> established and consistent meaning: it is used for name binding.
> 
> Things which look similar should be similar. "i as int" and "module as name"
> look similar, but they are the same syntax for different concepts. "foo as
> bar" will sometimes mean that bar is the name bound to foo, and sometimes
> it will mean that foo is declared to be type bar. That's messy and
> inconsistent and best avoided.

On the other hand, flip it around and say:

def sqrt(int as i):

and now the name-binding semantics works.  "The first argument is an 
int, which is bound to the name i".  Not sure how you would apply that 
to the return type, though.

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#84359

On Sat, Jan 24, 2015 at 12:23 AM, Fetchinson .
<fetchinson@googlemail.com> wrote:
> 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?

Is there any particular reason for the number of arguments to be part
of the function signature? I totally get the notion of declaring how
many arguments a function takes, but why does it have to be in the
function signature?

Data types are just as much a part of that signature as argument count
is. You could argue that the function's return type isn't part of
that, but that's about it.

> If there is a pep for it, people will use it, so the fact that
> it is optional is irrelevant...

Function annotations were introduced in 2006 (Python 3.0) with PEP 3107:

https://www.python.org/dev/peps/pep-3107/

They were optional then, they are still optional now. Have you been
overrun with them for the past decade? If not, why do you expect now
to be?

ChrisA

[toc] | [prev] | [next] | [standalone]

#84402

On 1/23/15, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jan 24, 2015 at 12:23 AM, Fetchinson .
> <fetchinson@googlemail.com> wrote:
>> 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?
>
> Is there any particular reason for the number of arguments to be part
> of the function signature?

I guess this is a rhetorical question :)

> I totally get the notion of declaring how
> many arguments a function takes, but why does it have to be in the
> function signature?

Ditto :)

> Data types are just as much a part of that signature as argument count
> is.

I guess this would be true if there weren't about 5 other alternative
proposals which solve the exact same problem (type hinting) by other
means. Luckily, these will be listed in the PEP soon and the reason
for rejecting them will be there as well, and so my question will
pretty much be answered there.

https://github.com/ambv/typehinting/issues/55


> You could argue that the function's return type isn't part of
> that, but that's about it.

>> If there is a pep for it, people will use it, so the fact that
>> it is optional is irrelevant...
>
> Function annotations were introduced in 2006 (Python 3.0) with PEP 3107:
>
> https://www.python.org/dev/peps/pep-3107/
>
> They were optional then, they are still optional now. Have you been
> overrun with them for the past decade? If not, why do you expect now
> to be?
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>


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

[toc] | [prev] | [next] | [standalone]

#84317

On Fri, Jan 23, 2015 at 4:03 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 1/22/2015 10:59 PM, Chris Angelico wrote:
>>
>> On Fri, Jan 23, 2015 at 2:22 PM, Terry Reedy <tjreedy@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.

Yep. It's not a killer, but it does have a cost. That's one reason for
doctests - to put the tests in with the code. Everything's a
trade-off; with tests it's often better to put them in another file,
but type hints are short and compact, and can be briefly stated.
Unlike the complicated ones this thread has given us, most real-world
ones will be short. So we have the option to put them in-line or out
of line, and the two options have competing costs (readability vs code
disconnect).

ChrisA

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web