In article <5afad59b-5e8c-4821-85cf-9e971c8c7...@googlegroups.com>, rantingrickjohn...@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. -- https://mail.python.org/mailman/listinfo/python-list