Python is DOOMED! Again!

[Steven D'Aprano]

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