asincero wrote: > Would it be considered good form to begin every method or function with > a bunch of asserts checking to see if the parameters are of the correct > type (in addition to seeing if they meet other kinds of precondition > constraints)? Like: > > def foo(a, b, c, d): > assert type(a) == str > assert type(b) == str > assert type(c) == int > assert type(d) == bool > # rest of function follows > > This is something I miss from working with more stricter languages like > C++, where the compiler will tell you if a parameter is the wrong type. > If anything, I think it goes a long way towards the code being more > self documenting. Or is this a waste of time and not really "the > Python way"? > > -- Arcadio
Many developers who move from a statically-typed languages to dynamic ones go through this same sort of thought process. I was no different in that regard, but as I've done more and more Python, I've found that I just don't encounter type issues all that often. Above all, I see duck typing as a net benefit - its inherent flexibility far outweighs the lack of "compile-time" type safety, in my mind. Along these lines, I'll point you to this article by Bruce Eckel called "Strong Typing vs. Strong Testing": http://www.mindview.net/WebLog/log-0025. The bottom line: Focus on unit tests rather than explicit type checks when you want to verify the runtime safety of your code. You'll find many more errors this way. Hope this helps... --dave -- http://mail.python.org/mailman/listinfo/python-list