[Python-3000] Abilities / Interfaces

[Kay Schluehr]

Greg Ewing schrieb:

>Gustavo Niemeyer wrote:
>  
>
>>Are you arguing that
>>pretty much every approach being discussed is bad and
>>we should instead implement something magically
>>transforming types?
>>    
>>
>
>No, I'm questioning the need to do anything at all.
>I don't see a big problem that merits a heavyweight
>solution like a formal interface or adaptation
>framework.
>
>--
>Greg
>_______________________________________________
>Python-3000 mailing list
>Python-3000 at python.org
>http://mail.python.org/mailman/listinfo/python-3000
>Unsubscribe: http://mail.python.org/mailman/options/python-3000/kay.schluehr%40gmx.net
>  
>
Seems like we need more formal procedures for writing test than 
application code. This also solves the problem of expense of 
"verification" of typeclasses/concepts/abilities that need to be done 
just once for a class with a fixed interface and not each time when the 
class gets loaded from a module. The value of "test time" is increased 
to a higher status not unlike the role of "compile time" for static 
analysis in languages with default type systems. But maybe my head is 
just too far in the clouds when I'm thinking about the end of the 
static/dynamic language distinction using type reconstruction at "test 
time". Heavyweight frameworks naturally emerge also in Python but being 
latent. Reconstructing them from runtime information is a challenge for 
dynamically typed languages. A good enough approximation can be turned 
into a set of prescriptions. This is not much different from the way 
natural scientists frame reality according to Karl Poppers "logic of 
progress" ( hypothetical deductive method ). Regular enough data are 
used to form a hypothesis about the future behaviour of a system. This 
hypothesis is used to frame reality in a mathematical description - just 
like type systems. Making new experiments / measurents can falsify a yet 
established deductive system which leads to improved frames ( reframing 
) and progressive understanding of systems properties. The role of tests 
in this approach is twofold: they check application code and keep 
information about the "true nature" of the programs behaviour using 
measurements which leads to automatical generation of a formal 
hypothesis of a systems behaviour that may become prescriptive i.e. 
forms a type system:

Note that I've not yet strong indications that a Popperian methodology 
really works for any kind of language including Python i.e. I have 
neither worked out a formal proof nor do I have a working system ( not 
to mention treatments of "singularities" ) But I believe enough in this 
idea for questioning the value of making "Python more Java like" which 
seems to be the main intention of the interface/ability/optional type 
declaration proposals discussed here.

Kay