Python Sanity Proposal: Type Hinting Solution

[Rick Johnson]

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!