Michael Chermside <mcherm <at> mcherm.com> writes: > Talin writes: > > Lets start a new top-level thread to discuss this specific > > proposal. > > tomer filiba writes: > > i'm sure my idea has flaws, but i'm very much pro-changing the type system. > [...] > > types are just an ancient relic, an implementation detail if you wish, that > > was brought from static languages, but is not appropriate to dynamic > > languages. static languages NEED types in order to produce machine > > code, dynamic languages don't, so a different mechanism is needed here, > > imho. > > I think the idea of creating a new language with some of the wonderful > syntax of Python along with the wonderful type system of Haskell sounds > GREAT! I would be very interested, and would like to join in the > discussion. > > But I don't think it belongs in the Python-3000 discussion group. Can > this discussion be moved elsewhere? Python 3.0 is going to have types, > and they're going to look very similar to the types in Python 2.X -- > a brand new language would be a separate project.
Ordinarily I would agree with you on this point, and in fact I wouldn't even bring it up at all, except for two data points: 1) The proposal to include generic function dispatch in Python 3000, based on explicit typing. 2) The proposal to remove all forms of type testing other than those based on isinstance() (in other words, removing callable, isSequence, isMapping, etc.) (I'm not including attribute testing here because its neither standardized nor systematic.) The net effect of these proposals is to greatly strengthen the capabilities of explicit typing, while seriously crippling the use of duck typing. By putting a much greater emphasis on explicit typing, we're effectively moving Python away from the implcit "duck-typing" that we've known up to this point. So essentially Python is *already* becoming a different language, whether we like it or not. I think that I agree with the gist of Tomer's point. I'm not going to claim that types are useless, but I think we should think about ways of dispatching other than types. What would seem very 'Pythonic' to me would be a system whereby objects can not only be dispatched on their types but also their *capabilities*. Thus, instead of asking the question "Is this a sequence?", we ask "Can this be iterated?" In such a model a "sequence type" would simply be a set of capabilities that often occur together. I think at the very least, we need a way a better definition of a "capability", and a formalized way to test for its presence. Whether or not that is directly wired into the dispatch mechanism (which would be cool) is another issue. Certainly attribute testing is part of it, but there needs to be agreement on which attributes to test. -- Talin _______________________________________________ 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
