Lars Yencken <l...@yencken.org> writes: > For example, if you are expecting to be passed in a list that you're > going to append to, or some compatible duck type
There's a misunderstanding here. “Duck typing” refers to a *principle* to be followed in the practice of programming; it is not an attribute of types themselves. It makes no sense to say that a type is “some compatible duck type”. That is, a list is not “a duck type”, nor is a list “not a duck type”. The program code that *uses* the object is either following the principle of duck typing – i.e. testing an object's type only by watching how the object behaves – or is not following that principle. The type of the object doesn't matter for that term. > you might add a statement to the top of your function: > > def f(l): > append = l.append > ... > append(v) > > at the top of your code. If you get some other incompatible type, it > fails early rather than in the bowels of your program. These kinds of > things really help you to be productive and safe in a duck-typing > world. Why is it a problem for the exception to be raised within the bowels of your program? I'm not saying there can't be a reason, but you haven't said what the problem is. In many cases, it is quite helpful that the bowels of your program is where you want the exception raised from. Without knowing what trouble this causes you, I don't know what to say. _______________________________________________ melbourne-pug mailing list melbourne-pug@python.org https://mail.python.org/mailman/listinfo/melbourne-pug
