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

[Mark Voorhies]

On Thursday, October 07, 2010 09:22:02 pm Seth Friedman wrote:
> 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.  

Agreed.  Any language will provide some of the features you want, and you'll
wind up implementing the rest yourself; the trick is to match your project to
the language that will do most of the heavy lifting for you (and quite often,
that language turns out to be Python).

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

The main thing that a more rigid language will do is to force type checking
even when you don't remember to ask for it.  Sometimes this is what you
want, sometime it isn't...

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

In some of these cases, the pythonic thing to do is to use duck typing; e.g.,
rather than checking for a list _type_, check that you've been passed an
iterable (deriving from any base).

> 
> I mean, what's wrong with code asserting that what it got passed was what
> was expected?  

Nothing, and I think most python programmers would support sanitizing your
inputs, but asserting certain properties of your inputs does not always imply
asserting that they are instances of specific class (and sometimes it does,
and that's okay too).

--Mark

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