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 1 of 3  [1] 2 3  Next page →

#84297 — Python Sanity Proposal: Type Hinting Solution

Note: This is the closest you're going to get to a PEP from me! 

Okay, i have found a solution to the type hinting problem 
that will appease both sides. On one side we have those who 
are proposing type hinting annotations within function sigs, 
and on the other side, we have those who oppose the 
implementation of type hinting via this method because of 
the readability concerns. The solution is move the type 
hinting syntax completely out of the source file and into 
another file -- think of it as a "Python Type Hinting Header 
File". 

============================================================ 
 Summary 
============================================================ 
  
(1) Agree on a file extension that python will recognize 
as containing "type hint specs". Unfortunately we cannot 
use ".pth", which would be the perfect acronym for "Python 
Type Hints", so choose something else. :-( 

(2) Define a spec for writing annotations that will map to 
funcs/methods of the same name. I would argue to keep the 
spec compact, but i really don't care about the spec at 
this point. 

      
============================================================ 
 Simplistic Example Code utilizing two files: 
============================================================ 

  # 
  # scriptA.py 
  # 
  def greeting(name): 
      return 'Hello ' + name 
      
  #     
  # scriptA.typehints 
  # 
  greeting{name:str} -> str 


============================================================ 
 Benefits: 
============================================================ 

(1) Removes the noisy syntax from the source file. Python 
code will remain as clean tomorrow as it is today. 
  
(2) Puts the onerous on the author *NOT* on the reader. 
This system utilizes a concept known as "Level Of Detail" 
(or LOD). LOD means that i should not need to see a type 
hint unless i *WANT* to see a type hint. You can think of 
it as akin to "Java @string resources".   

(3) If i decide i don't want type hints in my code, all i 
have to do is delete or rename a file, which is much less 
error prone then editing source code. 

(4) Has the added benefit of aiding when debugging type hints. 
  
-- 
  
My suggestion is the only way to implement type hints 
without destroying Python! I just hope that GvR will give it 
serious objective consideration. 

[toc] | [next] | [standalone]

#84303

On 2015-01-23 01:15, Rick Johnson wrote:
>
> Note: This is the closest you're going to get to a PEP from me!
>
> Okay, i have found a solution to the type hinting problem
> that will appease both sides. On one side we have those who
> are proposing type hinting annotations within function sigs,
> and on the other side, we have those who oppose the
> implementation of type hinting via this method because of
> the readability concerns. The solution is move the type
> hinting syntax completely out of the source file and into
> another file -- think of it as a "Python Type Hinting Header
> File".
>
> ============================================================
>   Summary
> ============================================================
>
> (1) Agree on a file extension that python will recognize
> as containing "type hint specs". Unfortunately we cannot
> use ".pth", which would be the perfect acronym for "Python
> Type Hints", so choose something else. :-(
>
> (2) Define a spec for writing annotations that will map to
> funcs/methods of the same name. I would argue to keep the
> spec compact, but i really don't care about the spec at
> this point.
>
>
> ============================================================
>   Simplistic Example Code utilizing two files:
> ============================================================
>
>    #
>    # scriptA.py
>    #
>    def greeting(name):
>        return 'Hello ' + name
>
>    #
>    # scriptA.typehints
>    #
>    greeting{name:str} -> str
>
>
> ============================================================
>   Benefits:
> ============================================================
>
> (1) Removes the noisy syntax from the source file. Python
> code will remain as clean tomorrow as it is today.
>
> (2) Puts the onerous on the author *NOT* on the reader.
> This system utilizes a concept known as "Level Of Detail"
> (or LOD). LOD means that i should not need to see a type
> hint unless i *WANT* to see a type hint. You can think of
> it as akin to "Java @string resources".
>
> (3) If i decide i don't want type hints in my code, all i
> have to do is delete or rename a file, which is much less
> error prone then editing source code.
>
> (4) Has the added benefit of aiding when debugging type hints.
>
>
You also need to handle methods.

A simple way would be to use indentation:

# scriptA.py
class Greeter:
     def __init__(self, name):
         self.name = name

     def greet(self):
         print('Hello,', self.name)

def greeting(name):
     return 'Hello ' + name

# scriptA.typehints
Greeter:
     __init__(self, name: str)
greeting{name: str} -> str


I'm not sure about the best format for functions within functions. This
repeats the function name:

# scriptB.py
def greet(name):
     def make_message():
         return 'Hello,' + name
     print(make_message())

# scriptB.typehints
greet(name: str)
greet:
     make_message() -> str


But a shorter version might not be clear:

# scriptB.typehints
greet(name: str):
     make_message() -> str


especially when the outer function has a hint for its return type!

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

#84304

On 1/22/2015 8:15 PM, Rick Johnson wrote:

> Okay, i have found a solution to the type hinting problem
> that will appease both sides. On one side we have those who
> are proposing type hinting annotations within function sigs,
> and on the other side, we have those who oppose the
> implementation of type hinting via this method because of
> the readability concerns. The solution is move the type
> hinting syntax completely out of the source file and into
> another file -- think of it as a "Python Type Hinting Header
> File".

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'.  I don't know what the extension is.  These will be 
used for the stdlib, which will not have annotations in the .py files

> (2) Define a spec for writing annotations that will map to
> funcs/methods of the same name. I would argue to keep the
> spec compact, but i really don't care about the spec at
> this point.

It will use the one  proposed, with whatever modification still to come.
I believe stub files can also be used for functions defined in C.

>   Simplistic Example Code utilizing two files:

>    # scriptA.py
>    def greeting(name):
>        return 'Hello ' + name

>    # scriptA.typehints
>    greeting{name:str} -> str

I believe stub files can also be used for functions defined in C.


>   Benefits:

> (1) Removes the noisy syntax from the source file. Python
> code will remain as clean tomorrow as it is today.

This will at least be an option.  You are and will be free to advocate 
that people always use stub files.

> (2) Puts the onerous on the author *NOT* on the reader.
> This system utilizes a concept known as "Level Of Detail"
> (or LOD). LOD means that i should not need to see a type
> hint unless i *WANT* to see a type hint.

One thing not discussed here (but was in the earlier python-ideas thread 
some months ago) is that some groups have standards for using some 
functions that is stricter than the function's full duck-typing 
generality.  A stub file allows a group to specify a restrictive use 
annotation for their static checker without putting lies into the code 
or doc of the function itself.

> (3) If i decide i don't want type hints in my code, all i
> have to do is delete or rename a file, which is much less
> error prone then editing source code.

If the annotations are in a separate file, deleting will hardly be 
necessary since the file will be ignored until one runs software that 
uses it.

> (4) Has the added benefit of aiding when debugging type hints.

I am not sure what you mean here.   It will be easier to temporarily 
comment out an incorrect annotation for a function, pending correction, 
when in a separate file.


-- 
Terry Jan Reedy

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

#84388

On Thursday, January 22, 2015 at 9:22:40 PM UTC-6, Terry Reedy wrote:
> On 1/22/2015 8:15 PM, Rick Johnson wrote:
> 
> > Okay, i have found a solution to the type hinting problem
> > that will appease both sides. On one side we have those who
> > are proposing type hinting annotations within function sigs,
> > and on the other side, we have those who oppose the
> > implementation of type hinting via this method because of
> > the readability concerns. The solution is move the type
> > hinting syntax completely out of the source file and into
> > another file -- think of it as a "Python Type Hinting Header
> > File".
> 
> This idea is so brilliant 

Well thank you kind sir. O:-)
 
> that it is already an option in mypy and is part of the new
> type-hint proposal.

An *OPTION*? If it is not mandatory then why bother? If
authors have a choice between writing type hints into func
sigs or writing them in a "stub file", then the natural
human behavior of "slothfulness" will bring about the
destruction of Python via syntactic noise. Heck, why don't
we just adopt the *REAL* fairness doctrine and make
indentation optional? 

> The separate type-hint files are called 'stub files'.  I
> don't know what the extension is. These will be used for
> the stdlib, which will not have annotations in the .py
> files

So are saying that stubs are mandatory for stdlib source but
optional everywhere else?

> > (1) Removes the noisy syntax from the source file. Python
> > code will remain as clean tomorrow as it is today.
> 
> This will at least be an option.  You are and will be free
> to advocate that people always use stub files.

Well i don't advocate from a selfish perspective here, i'm
trying to save this community! Even though no human cannot 
escape his inherent emotional being, *some-of-us* do 
understand the importance of rational judgment when making 
important decisions!

> > (2) Puts the onerous on the author *NOT* on the reader.
> > This system utilizes a concept known as "Level Of Detail"
> > (or LOD). LOD means that i should not need to see a type
> > hint unless i *WANT* to see a type hint.
> 
> One thing not discussed here (but was in the earlier
> python-ideas thread some months ago) is that some groups
> have standards for using some functions that is stricter
> than the function's full duck-typing generality.  A stub
> file allows a group to specify a restrictive use
> annotation for their static checker without putting lies
> into the code or doc of the function itself.

Yes, there is nothing worse than lies, and comments are already
full of them. Yet again another reason to *FORCE* stub file usage!

> > (3) If i decide i don't want type hints in my code, all i
> > have to do is delete or rename a file, which is much less
> > error prone then editing source code.
> 
> If the annotations are in a separate file, deleting will
> hardly be necessary since the file will be ignored until
> one runs software that uses it.
> 
> > (4) Has the added benefit of aiding when debugging type hints.
> 
> I am not sure what you mean here. It will be easier to
> temporarily comment out an incorrect annotation for a
> function, pending correction, when in a separate file.

To tell you the truth I had not even considered allowing
commenting in the stub files, i was primarily focused on
*EXPORTING* the hints, so you are correct!

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

#84495

Am 23.01.15 um 20:23 schrieb Rick Johnson:
> On Thursday, January 22, 2015 at 9:22:40 PM UTC-6, Terry Reedy wrote:
>> that it is already an option in mypy and is part of the new
>> type-hint proposal.
> 
> An *OPTION*? If it is not mandatory then why bother? If
> authors have a choice between writing type hints into func
> sigs or writing them in a "stub file", then the natural
> human behavior of "slothfulness" will bring about the
> destruction of Python via syntactic noise. Heck, why don't
> we just adopt the *REAL* fairness doctrine and make
> indentation optional? 

Actually, optional indentation is not a bad idea in itself. For example
in Haskell, you can use indentation much in the same way as you use it
in Python. But you can also add semicolons and braces instead, which
override the indentation, on a per-statement basis. This permits more
freedom in code layout, for example it allows reasonable one-line ifs.


	Christian

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

#84305

On Friday, January 23, 2015 at 6:45:39 AM UTC+5:30, Rick Johnson wrote:
> Note: This is the closest you're going to get to a PEP from me! 
> 
> Okay, i have found a solution to the type hinting problem 
> that will appease both sides. On one side we have those who 
> are proposing type hinting annotations within function sigs, 
> and on the other side, we have those who oppose the 
> implementation of type hinting via this method because of 
> the readability concerns. The solution is move the type 
> hinting syntax completely out of the source file and into 
> another file -- think of it as a "Python Type Hinting Header 
> File". 
> 
> ============================================================ 
>  Summary 
> ============================================================ 
>   
> (1) Agree on a file extension that python will recognize 
> as containing "type hint specs". Unfortunately we cannot 
> use ".pth", which would be the perfect acronym for "Python 
> Type Hints", so choose something else. :-( 
> 
> (2) Define a spec for writing annotations that will map to 
> funcs/methods of the same name. I would argue to keep the 
> spec compact, but i really don't care about the spec at 
> this point. 
> 
>       
> ============================================================ 
>  Simplistic Example Code utilizing two files: 
> ============================================================ 
> 
>   # 
>   # scriptA.py 
>   # 
>   def greeting(name): 
>       return 'Hello ' + name 
>       
>   #     
>   # scriptA.typehints 
>   # 
>   greeting{name:str} -> str 
> 

1. Allow in same file
2. Chage syntax slightly to
type greeting : str -> str

[type is the keyword equivalent to your other typehint file ]
 and you have essentially the Haskell solution.

The catch I expect is that haskell is strongly committed to simultaneous
definitions:

x = 1
y = x+2

is the same as
y = x+2
x = 1

and so definitions can generally be permuted around

Python is committed to the opposite extreme:
even def and class are not declarative but imperative

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

#84389

On Thursday, January 22, 2015 at 9:24:01 PM UTC-6, Rustom Mody wrote:
     
> > ============================================================ 
> >  Simplistic Example Code utilizing two files: 
> > ============================================================ 
> > 
> > [...snip code example...]
> > 
> 1. Allow in same file
> 2. Change syntax slightly to:
>    type greeting : str -> str

While i'll agree that removing the hints from sigs is better
than the alternative of injecting noise into sigs, i still
feel as though type hints will "dirty" the purity of source
no matter how wonderful the declaration might to be.

I believe strongly that LOD is the only method we can apply
that will allow us to "bolt on" non-destructive type hints
in Python. So although your idea is an improvement, i'm
sticking with the "stub file solution". (unless something 
better is offered)

> [type is the keyword equivalent to your other typehint file ]
>  and you have essentially the Haskell solution.
> 
> The catch I expect is that haskell is strongly committed to simultaneous
> definitions:
> 
> x = 1
> y = x+2
> 
> is the same as
> y = x+2
> x = 1
> 
> and so definitions can generally be permuted around
> 
> Python is committed to the opposite extreme:
> even def and class are not declarative but imperative

I'm sorry, but i was unable to understand how your last
point was relevant to type hints? 

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

#84312

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. Use of stub files for something
that's only occasionally run (the type-checking linter) increases the
potential time delay between the error and the fix. Unless you make a
git/hg hook that runs type checks, chances are you'll have those
issues in your code.

Stub files are useful, but they aren't going to magically solve
everyone's complaints.

ChrisA

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

#84391

On Thursday, January 22, 2015 at 10:04:29 PM UTC-6, Chris Angelico wrote:

> 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.

I wonder how that "poor python interpreter" keeps all those
.pyc and .pyo files in sync with constantly changing source
code? It should be tantamount to torture! Will someone
*PLEASE* start a charity site titled: "Python's sanity fund"?

> Use of stub files for something that's only occasionally
> run (the type-checking linter) increases the potential
> time delay between the error and the fix. Unless you make
> a git/hg hook that runs type checks, chances are you'll
> have those issues in your code.
> 
> Stub files are useful, but they aren't going to magically
> solve everyone's complaints.

We're not trying to solve everyone's complaints, we're
trying to formulate a solution that will cause the least
amount (or completely avert) violating Python's design
philosophy. You act as if the "type hint fan-boys" are the
*ONLY* side of this coin, well, i here to inform you that
coins are two-sided!

Even though type hints may be useful to many programmers,
i'm sure equally as many will find no use for them. But
emotion and opinions *ALONE* is not a wise basis for ANY
decision making.

Therefore, the "MANDATORY-STUB-FILE-SOLUTION" is the *ONLY*
solution (offered so far) that can maintain Python's
philosophical goals whilst appeasing both sides of this two
faced coin.

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

#84394

On Sat, Jan 24, 2015 at 6:48 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Thursday, January 22, 2015 at 10:04:29 PM UTC-6, Chris Angelico wrote:
>
>> 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.
>
> I wonder how that "poor python interpreter" keeps all those
> .pyc and .pyo files in sync with constantly changing source
> code? It should be tantamount to torture! Will someone
> *PLEASE* start a charity site titled: "Python's sanity fund"?

That's where one is directly derived from the other. Edit the .py
file, rebuild the .pyc from it. Any dumb machine can do that... as
long as timestamps can be relied on, the hard drive is correctly
retaining data, etc, etc, etc. And guess what? Python isn't perfect at
it. I had a bizarre problem a while ago that came down to an incorrect
.pyc file in the stdlib. (I still have no idea how that came to be
incorrect. The hard drive doesn't seem to be failing, and the
corruption in the file looks more like a software bug than a hardware
issue.)

ChrisA

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

#84400

On Friday, January 23, 2015 at 1:59:38 PM UTC-6, Chris Angelico wrote:
> On Sat, Jan 24, 2015 at 6:48 AM, Sir Rick Johnson wrote:
> > On Thursday, January 22, 2015 at 10:04:29 PM UTC-6, Chris Angelico wrote:
> >
> >> 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.
> >
> > I wonder how that "poor python interpreter" keeps all those
> > .pyc and .pyo files in sync with constantly changing source
> > code? It should be tantamount to torture! Will someone
> > *PLEASE* start a charity site titled: "Python's sanity fund"?
> 
> That's where one is directly derived from the other. Edit the .py
> file, rebuild the .pyc from it. Any dumb machine can do that... as
> long as timestamps can be relied on, the hard drive is correctly
> retaining data, etc, etc, etc. 

Okay, you make a fair point, so let's dig beyond the
superficiality and find the truth shall we? I don't care who
wins, i just want to find the truth.

Your assertion is that since "external hints" are not
directly visible when reading source (as they would be in
func sigs) that the author will forget to update them???

Heck, do you ever read comments? Many of them are not only
out of sync with the code they describe (because an author
forgot to update a corresponding comment after changing the
code), in some cases, they are not even in sync with
*REALITY* (this case being where the author cannot
articulately describe what the code is doing and the
comments become misleading) 

    Yes, there are programmers out there who can write 
    perfectly functioning code but cannot describe what
    it is doing with even a modicum of coherency! Do the 
    phrase "word salad" mean anything to you?

So after observing the lunacy of comment authors, arguing
that by placing hints in source (as opposed to exporting them
to stub files) is somehow going to "magically enforce"
synchronicity -- you have more faith in others than i do!

> And guess what? Python isn't perfect at it. I had a
> bizarre problem a while ago that came down to an incorrect
> .pyc file in the stdlib. (I still have no idea how that
> came to be incorrect. The hard drive doesn't seem to be
> failing, and the corruption in the file looks more like a
> software bug than a hardware issue.)

I too have encountered, when doing some heavy *EDIT-RUN-
EDIT* sessions, where Python was still using an old pyc file
that did not correctly sync with the modified code in my
editor.

And in some cases i was able to verify the bug by changing a
symbol and noting that the exception reports a reference to
the old (now non-existent) symbol.

Sadly when this happens i am usually too busy to stop and
spend time chasing down the source: is it my editor, or is
this a Python issue, or something more subtle??? My quick fix
is to run a Python script that deletes all my .pyc files and
everything is all peaches and cream again.

    Mmm, peaches!

So yes, anecdotal evidence does support your argument that:
"machines can screw up".

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

#84401

In article <5afad59b-5e8c-4821-85cf-9e971c8c7be6@googlegroups.com>, 
rantingrickjohnson@gmail.com says...
> 
> On Thursday, January 22, 2015 at 10:04:29 PM UTC-6, Chris Angelico wrote:
> 
> > 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.
> 
> I wonder how that "poor python interpreter" keeps all those
> .pyc and .pyo files in sync with constantly changing source
> code? It should be tantamount to torture! Will someone
> *PLEASE* start a charity site titled: "Python's sanity fund"?
> 

The process is automatic and based exclusively on timestamps. What you 
propose is manual labor and therein lies the rub. You have to remember 
to update your static analysis files when you update your code. And it 
is not always easy to do it, especially in team development 
environments.

This is also going to complicate user work and the static analysis 
parser work. Function headers need to be matched with the annotated 
description in another file. Because of namespaces this will leave room 
for ambiguity, unless you mirror in the type hinting file the complete 
function signature, which must include its namespace. That is, you need 
a syntax that at the very least includes class declarations, but should 
probably also consider local namespaces and modules. All because you are 
not matching directly a type annotation with the type declaration in the 
code.

...

In any case, I agree entirely with you that type annotation is one ugly 
syntax to a programming language that is touted everywhere as being 
simple and easy to read. I would say that the mistake started 5 years 
ago, and I am surprised how you guys let that horrible PEP pass. I 
wasn't around then, so I'm off the hook.

Some folks in here argue that complex type annotations will be rare, 
since functions should be designed as straightforward units of code with 
simple requirements and respecting certain best practices, like 
separation of concerns, low cyclomatic complexity, adapt well to simple 
unit tests, bla bla bla. But the actual practice of coding software is 
very different. We generally code bad software and generally avoid best 
practices if they get in the way of our schedules, our knowledge, and 
even our ability. And there is always the problem of OOP, which is a 
magnificent source of complex function declarations in terms of the 
types they receive and output.

I think that you are right in that we shouldn't pollute our code with 
static analysis shit. We shouldn't pollute our code period. But There's 
better ways of doing it without resorting to external files.

I'd say Steven D'Aprano example of Cobra hit my sweet spot.

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

#84404

On Friday, January 23, 2015 at 3:02:57 PM UTC-6, Mario Figueiredo wrote:

> In any case, I agree entirely with you that type
> annotation is one ugly syntax to a programming language
> that is touted everywhere as being simple and easy to
> read. I would say that the mistake started 5 years ago,
> and I am surprised how you guys let that horrible PEP
> pass. I wasn't around then, so I'm off the hook.
> 
> Some folks in here argue that complex type annotations
> will be rare, since functions should be designed as
> straightforward units of code with simple requirements and
> respecting certain best practices, like separation of
> concerns, low cyclomatic complexity, adapt well to simple
> unit tests, bla bla bla. But the actual practice of coding
> software is very different. We generally code bad software
> and generally avoid best practices if they get in the way
> of our schedules, our knowledge, and even our ability. And
> there is always the problem of OOP, which is a magnificent
> source of complex function declarations in terms of the
> types they receive and output.
> 
> I think that you are right in that we shouldn't pollute
> our code with static analysis shit. We shouldn't pollute
> our code period. But There's better ways of doing it
> without resorting to external files.
> 
> I'd say Steven D'Aprano example of Cobra hit my sweet
> spot.

Yes and this is what i meant when i said "cutting the baby
in half". Although stub files have many advantages, i'll
admit they are onerous for the authors. So the compromise
would be to keep the hints in the same file for which they
are applied, but to separate them from the func arguments:

    (Example modified for PEP8 compliance ;-)

    @typehint(arg1:str, arg2:int, returns:bool)
    def myfunction(arg1, arg2): 
        return True 
        
Of course "@typehint" could be an extension of the decorator
syntax, a keyword, a build-in function or whatever, i don't
care.

That's an acceptable compromise for me. It's not completely
satisfactory, but at least i can read parameters without
needing to ignore type noise -- gawd that is so
annoying!

    Today's repressed look of disapproval brought to you by:
    Angry Java Programmers Everywhere!

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

#84409

In article <4b3b498a-c9b0-443d-8514-87ccd8e98f43@googlegroups.com>, 
rantingrickjohnson@gmail.com says...
> 
>     (Example modified for PEP8 compliance ;-)
> 
>     @typehint(arg1:str, arg2:int, returns:bool)
>     def myfunction(arg1, arg2): 
>         return True 
>         
> Of course "@typehint" could be an extension of the decorator
> syntax, a keyword, a build-in function or whatever, i don't
> care.

I'd rather it'd be a docstring parameter.

- Decorators are transformation tools. Which type hints are not.
- keywords should be few and used only for language features. Static 
analysis isn't and should never be a language feature. It's an 
extension, perhaps.
- Same with built-in functions... although a case could be made for a 
static analysis package, hmmm.

So I'd rather see:

     def myfunction(arg1, arg2):
     """
     Normal docstring.
     """ 
     "@typehint: (str, int) -> bool"
         return True 

This conforms to PEP 258, but not to PEP 8, but you can always use the 
triple quotes. I would just use the single-quote myself for matters of 
taste.

I removed the arguments names on purpose. They are only necessary on the 
PEP because type hinting is a part of the function header there. 
However, when using a documentation like pattern as above (or as in your 
own example), they can be safely removed, with the added benefit of 
making the syntax simpler.

Alternatively, because dangling strings are always considered 
documentation and completely ignored by the interpreter (PEP 258), one 
could also do:

     "@typehint: (str, int) -> bool"
     def myfunction(arg1, arg2):
     """
     Normal docstring.
     """ 
         return True 

Again the choice of triple quotes or not is something not worth 
debating.

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

#84410

In article <MPG.2f2cecb4624e49c498968c@nntp.aioe.org>, marfig@gmail.com 
says...
> 
> 
> So I'd rather see:
> 
>      def myfunction(arg1, arg2):
>      """
>      Normal docstring.
>      """ 
>      "@typehint: (str, int) -> bool"
>          return True 
> 

Actually that is idiotic. Much better is:

      def myfunction(arg1, arg2):
      """
      Normal docstring...
      @typehint: (str, int) -> bool
      """ 
          return True 

Why would I need to insert an extra docstring, if I'm already defining a 
parameter?

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

#84413

On Friday, January 23, 2015 at 2:46:01 PM UTC-8, Mario Figueiredo wrote:
> In article <MPG.2f2cecb4624e49c498968c@nntp.aioe.org>, marfig@gmail.com 
> says...
> > 
> > 
> > So I'd rather see:
> > 
> >      def myfunction(arg1, arg2):
> >      """
> >      Normal docstring.
> >      """ 
> >      "@typehint: (str, int) -> bool"
> >          return True 
> > 
> 
> Actually that is idiotic. Much better is:
> 
>       def myfunction(arg1, arg2):
>       """
>       Normal docstring...
>       @typehint: (str, int) -> bool
>       """ 
>           return True 
> 
> Why would I need to insert an extra docstring, if I'm already defining a 
> parameter?

I really like that implementation.

Its unobtrusive and doesn't clutter the function definition, and putting in the docstring makes it get colored like a comment (At least, with my IDE setup it does) so it is easily ignored by my eyes as I'm scrolling through.

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

#84418

In article <c1d9c448-31b0-4bbc-8c6f-5194678a6f87@googlegroups.com>, 
sohcahtoa82@gmail.com says...
> 
> >       def myfunction(arg1, arg2):
> >       """
> >       Normal docstring...
> >       @typehint: (str, int) -> bool
> >       """ 
> >           return True 
> > 
> 
> I really like that implementation.
> 
> Its unobtrusive and doesn't clutter the function definition, and
> putting in the docstring makes it get colored like a comment (At
> least, with my IDE setup it does) so it is easily ignored by my eyes
> as I'm scrolling through.

It has the side effect of being included in __doc__. A purist may have 
an issue with that, since type hinting, for the purposes of static 
analysis, should have no place in that attribute.

But you could always fall back to the previous version:

       def myfunction(arg1, arg2):
       """
       Normal docstring...
       """
       "@typehint: (str, int) -> bool"
           return True 

And __doc__ would be free of it. It would be up to the user to choose.

For something completely different, I like @hint: better than @typehint:

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

#84422

Mario Figueiredo <marfig@gmail.com>:
> Much better is:
>
>       def myfunction(arg1, arg2):
>       """
>       Normal docstring...
>       @typehint: (str, int) -> bool
>       """ 
>           return True 

I seem to remember an idea floated on the Scheme mailing list of using
assertions for such a purpose:

   def myfunction(arg1, arg2):
       assert isinstance(arg1, str) and isinstance(arg2, int)
       return True

The advantage is that the assertions can be as complex as you'd like:

   def weekday(day):
       assert isinstance(day, int) and 0 <= day <= 6
       ...

   def str_product(x, y):
       assert isinstance(x, int) and isinstance(y, str) or \
           isinstance(x, str) and isinstance(y, int)
       ...

Also, they have always been present in the language and assertion
semantics is fully compatible with static analysis.

Only I'd hate if that style became standard boilerplate...


Marko

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

#84436

Marko Rauhamaa wrote:

> I seem to remember an idea floated on the Scheme mailing list of using
> assertions for such a purpose:
> 
>    def myfunction(arg1, arg2):
>        assert isinstance(arg1, str) and isinstance(arg2, int)
>        return True
> 
> The advantage is that the assertions can be as complex as you'd like:
> 
>    def weekday(day):
>        assert isinstance(day, int) and 0 <= day <= 6
>        ...
> 
>    def str_product(x, y):
>        assert isinstance(x, int) and isinstance(y, str) or \
>            isinstance(x, str) and isinstance(y, int)
>        ...
> 
> Also, they have always been present in the language and assertion
> semantics is fully compatible with static analysis.

Not really. Well, I suppose technically they could be, if the type-checker
included a full Python interpreter.

Requiring the type-checker to parse and understand arbitrarily complex
assertions would require the type-checker to be as complex as Python
itself:


def f(something):
    assert (__import__("somemodule") is 
            some_function(spam, eggs, *ham, **cheese).attr.x[y](z) or
            any(some_expression and another_expression
                for a, b, c, d in my_module.map(something, fe, fi, fo, fum)
                if some_condition(a) or b == c[d]) and
            are_you_confused_yet() if foo else bar or eval(expr, ns) < 23
            or open('config').read(100)[23:27] == 'okay')


Fortunately, type systems are generally not fully Turing complete and are
usually significantly more restricted. PEP 484 doesn't mandate an upper
limit to how clever the type-checker must be, it only sets a common syntax
which type-checkers are expected to support. That is significant less
complex than a full Python parser, and should be lightweight enough that
IDEs and editors can use type-hints for providing text completion and
hints.

(This means that type-checkers are permitted to parse assertions, but they
aren't required to.)

Assertions also have the problem that they execute arbitrarily complex code
at runtime. Type annotations also execute code at runtime, but they're not
expected to be arbitrarily complex: mostly name lookups.

Lastly, this use of assertions clashes with "best practice" for assertions.
Since assertions may be disabled, you should not use them for testing
user-supplied arguments. So that means you have to write:

def func(arg):
    assert isinstance(arg, int)  # satisfy the type checker
    if isinstance(arg, int):  # support times when assert is disabled
        ...


which is not only ugly, but every call requires *two* isinstance checks. It
also means that when asserts are enabled you get a different exception for
bad data than when they are disabled.

This doesn't apply to annotations:

def func(arg:int):
    # since this is a public function, not private, we cannot assume the
    # caller will run the type-checker
    if isinstance(arg, int):
        ...

In this case, the overhead from the "arg:int" annotation is trivial: a
single name lookup and binding when the function is created, not when it is
called.

Sufficiently clever type-checkers may use assertions to infer types, but
requiring this is a non-starter.



-- 
Steven

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

#84437

On Sat, Jan 24, 2015 at 4:29 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Sufficiently clever type-checkers may use assertions to infer types, but
> requiring this is a non-starter.

Or they could use the isinstance checks themselves to infer types.

def func(arg):
    if not isinstance(arg, int): raise ValueError("Expected an integer")

It's fairly straight-forward to do an AST parse on a module, iterate
over it for functions, and then look for a specific pattern like the
above:

If(test=UnaryOp(op=Not(), operand=Call(func=Name(id='isinstance',
ctx=Load()), args=[Name(id='arg', ctx=Load()), Name(id='int',
ctx=Load())], keywords=[], starargs=None, kwargs=None)),
body=[Raise(exc=Call(func=Name(id='ValueError', ctx=Load()),
args=[Str(s='Expected an integer')], keywords=[], starargs=None,
kwargs=None), cause=None)], orelse=[])

... okay, that's not exactly pretty, but it's still a straight-forward
structure. But having just watched a PyCon talk about PyPy and RPython
and type inference, it's pretty clear that static analysis can do a
*lot* more than this; so really, looking for isinstance checks is both
too hard and too simplistic to be really worth doing. Type hinting is
a different beast.

ChrisA

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web