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! -- https://mail.python.org/mailman/listinfo/python-list