Lars Yencken writes:
> I haven't mastered it, but there seems to be an art to testing your type
> assumptions early in Python.
The art is: Don't test data type assumptions in the code.
Rather, use EAFP and duck typing, and only test type assumptions in unit
tests.
Duck typing means that you s
Lars Yencken 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 the
Hi, Ben, unit test is not the problem.
I have a sorted list. I can put in all numeric or all strs, or any
type that's orderable to all the others:
>>> sorted_list(1, 3, 5.0, 7, 6, 4, 2.0)
[1, 2.0, 3, 4, 5.0, 6, 7]
>>> sorted_list('a', 'c', 'e', 'd', 'b')
['a', 'b', 'c', 'd', 'e']
But if I put in
On 5 September 2013 14:48, Ben Finney wrote:
> Lars Yencken 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 p
On 5 September 2013 14:48, Ben Finney wrote:
> 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.
>
The earlier you catch the error, the faster you can debug the source
proble