Python Sanity Proposal: Type Hinting Solution

[Mario Figueiredo]

In article <5afad59b-5e8c-4821-85cf-9e971c8c7be6 at googlegroups.com>, 
rantingrickjohnson at gmail.com says...
> 
> On Thursday, January 22, 2015 at 10:04:29 PM UTC-6, Chris Angelico wrote:
> 
> > It's worth pointing out, too, that the idea isn't
> > panaceaic - it's just another tool in the box. Any time
> > you break related things into separate places, especially
> > separate files, the tendency for them to get out of sync
> > grows dramatically.
> 
> I wonder how that "poor python interpreter" keeps all those
> .pyc and .pyo files in sync with constantly changing source
> code? It should be tantamount to torture! Will someone
> *PLEASE* start a charity site titled: "Python's sanity fund"?
> 

The process is automatic and based exclusively on timestamps. What you 
propose is manual labor and therein lies the rub. You have to remember 
to update your static analysis files when you update your code. And it 
is not always easy to do it, especially in team development 
environments.

This is also going to complicate user work and the static analysis 
parser work. Function headers need to be matched with the annotated 
description in another file. Because of namespaces this will leave room 
for ambiguity, unless you mirror in the type hinting file the complete 
function signature, which must include its namespace. That is, you need 
a syntax that at the very least includes class declarations, but should 
probably also consider local namespaces and modules. All because you are 
not matching directly a type annotation with the type declaration in the 
code.

...

In any case, I agree entirely with you that type annotation is one ugly 
syntax to a programming language that is touted everywhere as being 
simple and easy to read. I would say that the mistake started 5 years 
ago, and I am surprised how you guys let that horrible PEP pass. I 
wasn't around then, so I'm off the hook.

Some folks in here argue that complex type annotations will be rare, 
since functions should be designed as straightforward units of code with 
simple requirements and respecting certain best practices, like 
separation of concerns, low cyclomatic complexity, adapt well to simple 
unit tests, bla bla bla. But the actual practice of coding software is 
very different. We generally code bad software and generally avoid best 
practices if they get in the way of our schedules, our knowledge, and 
even our ability. And there is always the problem of OOP, which is a 
magnificent source of complex function declarations in terms of the 
types they receive and output.

I think that you are right in that we shouldn't pollute our code with 
static analysis shit. We shouldn't pollute our code period. But There's 
better ways of doing it without resorting to external files.

I'd say Steven D'Aprano example of Cobra hit my sweet spot.