On Mon, 26 Jan 2015 17:10:18 -0800, Rick Johnson wrote: > On Monday, January 26, 2015 at 6:12:00 PM UTC-6, Steven D'Aprano wrote: > >> Stub files are a second-rate solution for the problem of annotating >> functions where you are unable (or unwilling) to annotate the source >> code directly. They suffer from similar problems: >> >> - you have to manage the stub file independently of the source code it >> belongs with >> >> - type information is about as far away from the variable as it >> is possible to get (a completely different file!) >> >> - lexical analysis has to look for twice as many files (it has to >> hit the hard drive for a stub file before looking at the source), and >> we know from importing that file system access is a significant and >> expensive part of the process. > > Funny how your example logically leads to the solution of your own > "partisan problem". > > At an early stage in the design process, most wise designers would > realize that: since stub files are optional, and therefore searching for > stub files *EVERY TIME* Python is reading a script is superfluous, then > the solution is to require a declaration in every file that wants > typehinting. In other words, put the onerous on the "typehint author" by > requiring a "typehint declaration" at the top of every file that has a > corresponding typehints stub.
Unfortunately that doesn't work. Stubs will be needed for extension modules written in C (or some other language), or built-in modules such as sys (which are built into the interpreter). So modules which will need your declaration won't have anywhere to put it! Likewise for byte-code only libraries (no source code distributed, just the .pyc files). And it does nothing to solve the problem that the type declaration is as far away from the parameters as it is possible to be. [...] >> But, when the first-rate solution cannot be used, a second-rate >> solution is better than nothing. > > Your synthetic "first rate vs second rate" dichotomy I'm sure that there are worse solutions that stub/header files. But splitting information about a single function over two files is by any standard sub-optimal. > is nothing more > than a highly subjective and one sided interpretation Just because I have considered and rejected your solution doesn't mean I haven't given it the thought it deserves. Rick, I'll admit that I was being a smart arse with my quip about the seventies wanting their bad ideas back. A separate header file is a reasonable solution to the problem of type hinting when you cannot or will not annotate the actual source. That makes it "bad" merely in a relative sense: it has serious disadvantages compared to in-place annotations, but it is still a workable solution when you can't annotate the source. Analogy: a spoon makes a really poor knife, but if you have nothing else on hand, you can cut vegetables and even the softer cuts of meat using the side of a spoon. > meant to paint the > opposition as wrong without offering any real evidence of > "wrongfulness". Rick, you just quoted me giving three reasons why stub files are less suitable than in-place annotations. How can you justify claiming that I'm not giving evidence of wrongfulness? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
