[Python-3000] Abilities / Interfaces
Kay Schluehr
kay.schluehr at gmx.net
Sat Nov 25 19:56:31 CET 2006
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
More information about the Python-3000
mailing list