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@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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
