[Baypiggies] Type checking - argument for it being bad practice?

[Seth Friedman]

Hi Mark,

Thanks for your response.

I can't quite wrap my head around your argument.  I don't think one or two
lines per input is a lot of / too much time gatekeeping input variables.
Philisophically I think I see your point, I'm trying to impose some rigidity
in a domain that doesn't like it.  But there are lots of other values that
python brings - it seems extreme to go to a different super-verbose language
just for type-checking.  Not to mention that I don't trust those other
languages to actually do it for me as well as python's assert(isinstance...)
style - Java for instance strikes me as a prime candidate for false-negative
type checking, they've got a lot of subtle type variations.

Is something like
assert(isinstance(inputNumber,isActuallyANumberWeExpected)) really that
cumbersome, aside from my long variable names?  The biggest examples I can
think of are the distinctions between number and string of number, and list
of numbers, which seem like totally legit "how far does this function need
to go" question, asserting what is expected seems to illuminate rather than
confuse.

I mean, what's wrong with code asserting that what it got passed was what
was expected?  If there's blind faith that stuff will just work beneath the
scenes, ok, but when i *know* it won't, why not fail there, and explicitly?
  If I write a function that can be called from python code or command line,
I might get a string of a number or an int, and I will probably forget 6
months from now what I wrote the code to handle, without some kind of
prompt.  The closer that prompt is to the disconnect, the better.

~seth

On Thu, Oct 7, 2010 at 8:20 PM, Mark Voorhies <mvoorhie at yahoo.com> wrote:

> On Thursday, October 07, 2010 07:32:18 pm Seth Friedman wrote:
> > Hi Baypiggies,
> >
> > I've encountered, a couple of times now, a sort of categorical "dont do
> > typechecking" attitude on various blog posts and I haven't seen rationale
> to
> > back it up.   Enough that I'm now curious: what's the deal?
> >
> > So I put the question to you all, typechecking: good or bad thing?  Or
> > pointless philosophical debate?
>
> The lack of type signatures in function declarations are in line with
> "Python
> as a rapid prototyping language" -- if you're spending a lot of lines on
> "gatekeeping"
> a function's arguments, you might be better off in a language that does
> that
> work for you (e.g., Java, C++, ...).  There is a similar argument for not
> putting
> a lot of work into enforcing private variables in Python.
>
> That said, I don't have a strong opinion on this, and I've heard the
> "traits" system
> in the Enthought Python Distribution recommended as a way to assert more
> control over the types that a function accepts.
>
> --Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/d9cf35da/attachment.html>