I would also add that if you need to check runtime constraints in your code, then the right mechanism is an assert.
There are a few reasons for my belief. IMO, runtime constraints should: * be side effect free * be able to be optimized away * clearly convey information to readers of your code Binding l.append (as an example) doesn't fulfill any of these criteria. It makes namespace changes, it looks like an optimization, rather than a type constraint. It confuses the reading of code which calls the bound append (is it a function? A bound method? What object is it affecting?). It's also not idiomatic (how would you convey that you expect an integer? or one of a selection of types?) which means that someone else can't clearly mentally separate code from annotation. Sorry to be strident about this, but I think these are important points. You could (and I would) argue that optional type annotation is a useful syntactic sugar for this common use case for assertions, with the side-effect of providing information for a JIT. You could also argue that none of this is necessary, and the best solution is to write a comprehensive test suite. I think there's something to be said for both positions. Toby.
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
