> It may also be that only a good unified solution to "A" is needed in order to > allow library and user code to be written "easier" to address "B","C" and > "D". > It may even be just doing "A" is a good enough 95% solution (works well > enough > for 95% of actual use cases) and nothing more needs to be done. <It's too > soon > to tell>
I guess this is sort of what I think. And I hate to add yet another framework/system to the Python system, thus my proposal to handle it all using the existing type system, by re-factoring the various base classes (file, sequence, number, list, mapping, string, etc.) into a set of interface types, and re-defining the base types as various combinations of these interface types (which may be abstract, or concrete -- we haven't really talked enough about specifics to know yet). This would give us a decent base to use later (or now) for adding a multi-method dispatching system, as well. And optional type annotations, etc. Bill _______________________________________________ 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
