PEP 3107 and stronger typing (note: probably a newbie question)
nagle at animats.com
Tue Jul 3 08:15:44 CEST 2007
Alex Martelli wrote:
> Donn Cave <donn at u.washington.edu> wrote:
>>In article <1i0ikru.1uccqtm1efnzn3N%aleax at mac.com>,
>> aleax at mac.com (Alex Martelli) wrote:
>>>"Dynamic typing is recommended", they conclude, "when programs must be
>>>as flexible as possible". I recommend reading the Agile Manifesto to
>>>understand why maximal flexibility is crucial in most real-world
>>>application programming -- and therefore why, in said real world rather
>>>than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
>>>dynamic typing is generally preferable, and not such a tiny issue as
>>>they make the difference to be.
>>I guess there may be more than one kind of flexibility. The language
>>I fool around with sometimes that has strong static typing is Haskell.
>>Though a relatively elementary Haskell programmer (the learning curve
>>with this language is something you would have to experience to believe),
> I do have (some of:-) that experience, and am reasonably at ease in
> Haskell (except when it comes to coding monads, which I confess I still
> have trouble wrapping my head around).
>>I feel that the type checking actually helps me program faster.
>>The compiler's check for structural correctness is after all for my
>>benefit, and expedites development and maintenance of code, in my
>>limited experience. The more extensive my changes, the more useful
>>the type checking is - I'm much more casual about significant code
>>revision when writing in Haskell, somewhat more casual when writing
>>in C, and worried when writing Python.
> Eckel's and Martin's well-known essays on why good testing can replace
> strict static type checking:
He's all over the place in that article. He really isn't talking
about strong typing at all. What he does make a case
for is dispatch by name without inheritance, or "duck typing".
But that, in fact, is a form of strong type checking. The effect is
as if "object" had an abstract function for every member function
in the whole program. (And, in fact, in Python you pay exactly the
dispatch cost that would take.)
The problem is that in both C++ and Java, the first round
of the type system was botched. C++ originally had neither
generics nor checked downcasting (a la "dynamic_cast").
Java originally lacked generics. Both languages added those
as bolt-ons, and it shows.
But, again, this really isn't a Python issue.
More information about the Python-list