[melbourne-pug] Data type assumptions in Python (was: Yesterday's MPUG session and going forward)

[Lars Yencken]

On 5 September 2013 14:48, Ben Finney <ben+python at benfinney.id.au> wrote:

> Lars Yencken <lars at 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”.
>

There's no misunderstanding, though perhaps I'm slightly abusing
terminology. When I say "a list or compatible duck type", I mean a list or
something that quacks like a list, in that it meets the list-like interface
we're actually using in the method.


> > 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.


I'll give two examples:

1. Large batch scientific jobs, where you might encounter a runtime error
after 30 mins (or worse, hours) of partial computation. Even having to wait
five minutes to generate an error is not that great. When we have the
option, failing earlier is definitely better here. For some top-level
methods, failing at the start is much better than failing in the middle.

2. Unicode, unicode, unicode. If you've had to debug code which accepted a
mix of strings and unicode, you'll know what a pain it is to get a unicode
error deep in the bowels of your app -- essentially the stacktrace is
useless, it doesn't explain well enough how the error got there. By
capturing assumptions about the input at the border of your stack, instead
of throughout it, you can save yourself a lot of pain. I imagine cases like
this were a big driver for the revamped string type in Python 3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/melbourne-pug/attachments/20130905/e88c276b/attachment-0001.html>