Rick Johnson wrote:
> 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".
The 1970s called, they want their bad ideas back.
I can do no better than to quote from the Go FAQs:
Dependency management is a big part of software development
today but the “header files” of languages in the C tradition
are antithetical to clean dependency analysis—and fast
compilation.
http://golang.org/doc/faq#What_is_the_purpose_of_the_project
Things that go together should appear together. Imagine a language where you
declared the function name in one file, the function parameters in a second
file, any default values in a third file, and the function body in a fourth
file. Ridiculous. Ideally, all these things should be found together,
preferably close enough for the reader to take it all in at a glance
(although some function bodies may be too large).
There may be times where splitting related things are unavoidable, but they
should be a last resort, only to be used when any other solution is
unacceptable.
We know from Pascal and other languages that declaring types in the
parameter list works well and is very readable:
function calc(a: Real, b: Real): Integer;
...
We also know from Pascal that separating the declaration from the value
doesn't work so well:
function calc(a: Real, b: Real): Integer;
var
x: Integer;
y: Real;
z: array[1...100] of Something;
begin
{code goes here}
{possibly a lot of it}
{and finally we get to this}
x = some_function(a, 2*b+1); {what's the type of x again?}
end;
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
