Best Practices

So, now that you know the typecheck package inside and out, let's talk about what you do with that knowledge.

When writing type requirements, work to specify the MOST GENERAL types that you wish to support, for both now and the future. The type requirements are something like a contract; you're telling users that you plan to accept anything of that type, for now and in the future. So in particular:

• Don't make type requirements too strict -- they will inhibit reuse. Except in special cases, don't specify int, long, or float; often Number will do. Likewise, don't specify str; typically String, a more general type, is what you want, or possibly even ImSequence or IsIterable(). Don't say bool, unless you really mean that you only want True or False.

  Typeclasses are your friend.

• On the other hand, don't make your type requirements too broad. Sure, maybe today's code would work for a sequence, but do you have future plans that would require something more specific? (This is a problem for languages that "automatically" determine the type, such as ML; ML computes the allowed type based on current code, but cannot possibly guess what you hope to do in the future). So while Mapping might work today, you might want to require users to stick with dicts if you think the future might require such a move.

So, in short: too strict, bad. Too broad, also bad. Just right, good.