Python Sanity Proposal: Type Hinting Solution

Rick Johnson rantingrickjohnson at
Fri Jan 23 02:15:28 CET 2015

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 

(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: 

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


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

More information about the Python-list mailing list