OK, I'm not resisting responding to some comments on the interface type declaration issue.
Interfaces are something that two of the major "framework" systems in Python (Zope and Twisted) have both found missing and wandered off in search of their own solution. If such a system existing and was codified into Python it would make it a lot easier for myself and others to actually rely upon bits of code crafted by other people; specifically feeling warm and fuzzy about you not going around and changing something deep in the guts of your modules that I am not going to find out about until five weeks after updating to the most recent release.I have found that framework upgrades work best when there are sufficient tests available with the framework and sufficient tests for the system using the framework. These tests reduce the magnitude of lots of problems, especially the scenario described here.
Are you saying that even with sufficient tests, from the supplier and in your own code, you are still getting surprised a month into an upgrade?
If not, which do you think would be the lowest risk experiment for addressing the problem: writing more tests for the framework and your code, or changing the language?
(Note: I am *not* asking if you think type declarations would in some way address this problem. I *am* asking which of these two alternatives would be the lowest risk experiment.)
4 comments:
Yes, I will concede that good testing facilities in my app and your framework would make this problem go away, and I think that this is a lower _risk_ scenario than typing. OTOH, I do not think that this is a lower _cost_ scenario. I am paying my coders to write code for our app, not write unit tests for someone else's module...
Perhaps I am just clinging to what I hope will be the only real use of this typing system (interface definition) in an attempt to pretend that the language weenies and sellers of useless esoteric programming functionality (decorators and generic functiosn anyone?) have not made serious inroads into what I had hoped would be a nice easy little language that got things done.
Obviously for an individual it makes more sense to adapt your code (i.e., more testing) than fork the language. But even then, people are using the language in non-traditional ways to achieve these goals; both Zope and PyProtocols go to some length and do some funky things to make interfaces and adapters friendlier. (Twisted is now using Zope interfaces, from what I understand.) This shows, rather empirically, that there is a tension among programmers, and sufficient desire that some movement is required; not necessarily new syntax, but something.
Part of the issue here is that unit tests don't do anything to address this problem. Unit tests aren't going to test across the boundaries where people are proposing interfaces -- between loosely coupled components. Note also that interfaces are more explicit about contracts between components than tests will be. For instance, an interface might demand a method which is not yet being used in your code or your usage; the interface makes it explicit that this method should still be defined, and so predicts future developments, not just current developments (half-implemented dictionary interfaces are a common example in Python, where interfaces would motivate people to finish the work).
Or two interfaces can match methods and signatures, but include extra information about the semantic differences between those interfaces; because it doesn't use duck typing, you won't accidentally mix semantics (you have to explicitly say which, if any, of those interfaces you support). This is particularly a problem with interfaces that define only a small number of methods, or use common methods like __call__.
The only way to test these is with system tests, and system tests are always incomplete, there's always some code path or combination you haven't tested. That's part of the point of unit tests -- to test completely at a fine-grained level, and rely on the robustness of the components and the robustness of their specifications to reliably combine them.
I've a very simmple position to all type related mumbo-jumbo. If it's getting between me and my problem, forcing me to be concerned with some language feature for the sake of getting off mentally it's the time I drop a language. Period.
Surely, people realize that this is "optional" type declaration; it is not mandatory type declaration. Is there some kind of fall through behaviour that may impact those that do not want to use type declarations?
I have always seen interfaces more of a "method exists guarantee" rather than anything type related. We can make interfaces tighter by specifying parameter types for an interface method, but I am not sure how it is type related to start with.
Post a Comment