Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #53205 > unrolled thread

Re: Interface and duck typing woes

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Interface and duck typing woes Cameron Simpson <cs@zip.com.au> - 2013-08-29 11:20 +1000
    Re: Interface and duck typing woes Roy Smith <roy@panix.com> - 2013-08-28 21:27 -0400

#53205 — Re: Interface and duck typing woes

On 29Aug2013 09:17, Chris Angelico <rosuav@gmail.com> wrote:
| On Thu, Aug 29, 2013 at 7:54 AM, Terry Reedy <tjreedy@udel.edu> wrote:
| > Depending on who the users will be, I might just not worry about it until an
| > exception is raised. If you try to protect against everything that you might
| > do wrong, you are on the road to madness, as the protection code might also
| > be buggy. (Too much testing has the same problem ;-).
| 
| I'd go further.
| 
| Do you believe that you can write code to catch every bug you might
| make? If so, you are naive and probably haven't spent much time
| programming yet :) And if not, then you must acknowledge that bugs
| WILL happen; therefore you will need to cope with them after the
| event. So rather than trying to prevent them all, just improve your
| means of coping, and you'll accomplish the same end with much less
| trouble.

I'm not so extreme. Yes, of course certain things will only show
at runtime and you should be prepared to have to deal with that.

However, when working in Java its type strictness caught a great
many simple brainfart logic errors by checking function signatures;
typically calling the wrong function/method or mangling arguments.
Getting this stuff up front was handy. Of course there's a price
there in terms of flexibility and all that wordy stuff defining the
functions in the first place. As an aside, you can also get a lot
of this checking in C with aggressive linting and making a bunch
of macros like:

  #define CNULL ((char *)NULL)
  #define CPNULL ((char **)NULL)

and so forth as needed - lint can then catch a lot of otherwise
unchecked comparisons.

Anyway, I digress. My point is that there are plusses to having
signature/type checking at coding time. It is not the Python Way,
but I surely cannot be alone in sometimes being frustrated chasing
a deeply nested runtime error that static type checking might have
found up front.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

"waste cycles drawing trendy 3D junk"   - Mac Eudora v3 config option

[toc] | [next] | [standalone]

#53208

In article <mailman.339.1377739246.19984.python-list@python.org>,
 Cameron Simpson <cs@zip.com.au> wrote:

> Anyway, I digress. My point is that there are plusses to having
> signature/type checking at coding time. It is not the Python Way,
> but I surely cannot be alone in sometimes being frustrated chasing
> a deeply nested runtime error that static type checking might have
> found up front.

One time when I really do miss static typing (and often emulate by 
sprinkling isinstance() assertions into my functions) is when I do a big 
refactoring.

I'll change (to pick a real example) Song.get(id) from taking an integer 
to taking an ObjectId.  I'll hunt through my source code to find all the 
places where I call Song.get(), but usually I'll miss a few.  The 
assertions will help me catch that quickly because I'll get an easy to 
understand exception thrown right at the first point of contact, rather 
than something cryptic happening 12 stack frames down, deep in the 
database layer.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web