Just good advice? = WAS("Re: getting system date")

[David Broadwell]

"Alex Martelli" <aleax at aleax.it> scribbled in red:
> The general idea of sanity checks is OK, and that's what the assert
> statement is for.
And far easier to read that what i had too.

> Applying this specifically to type checking is not wise.
Perhaps i should just forbid strings ... as on my first run, I got very
confuzed when a string made it though a series of functions because
of a type error in a oneliner. Took a debug run to find it.

> Ask yourself, *WHY*?  What horrid fate would befall civilization as we
> know it if zoobar was to be called with, e.g., an instance of array.array,
> or of UserList.UserList, instead of a bona fide list?
Hadn't considered arrays, or even dictionaries. I'm not exactly thinking
in those yet. I beleve i have a handle on lists and strings ... and i'm
working on the dicts.

> The answer almost invariably is, nothing terrible would result: the code
> would work just as well, polymorphically -- by transparently accepting
> any type which is signature-polymorphical to lists, zoobar would just be
> more flexible, generally usable, natural, and useful.
Good point.

> that's just as good as failing a microsecond earlier
> with [whatever other exception -- btw, you seem not to use exceptions
> in your 'paranoia tests'... you should!], more often than not.
Too true ... had trouble guesing all of the variable errors that could be
thrown, kinda set that to the back burner of groking dicts.

> Occasionally it's handier to fail 'as soon as possible' when the argument
> type is inappropriate -- this is often easy to achieve through a little
> micro-optimization.
> def anotherway(alist):
>     append = alist.append
>     sort = alist.sort
>     for x in lotsofstuff:
>         append(x)
>     sort()
>
> this will be a little bit faster in normal successful operation AND
> will fail ASAP if alist lacks either an append OR a sort method.  It's
> not bomb-proof (you can't be sure that append is callable with each
> of the x values, nor that sort is callable w/o arguments), but it's
> quite good.
> You might add some little amount of innocuous paranoia:
And the 'paranoia' staement is just a old sysadmin thing ...
'Never met a really good admin that wasn't at least a little paranoid.'

> > # paranoia type tests ... bad coder, no biscut.
I was exagerating, but it made the point.

> > So, question is; in the long run, are these kind of tests worth it?
> No: they employ substantial effort in order to reduce the usefulness
> of a piece of code by inappropriate reliance on implementation (type)
> rather than interface ("signatures").  *Code to an interface, NOT to
> an implementation*.
This dosen't totally make sence yet, but then I've more reading to do
about this signature thing too.

> > And; what kind are the best 'parnaoia' tests to do?
> Whether some object has a required attribute (often best: get the
> attribute, so an AttributeError gets raised on failure, and if no
> exception occurred use the attribute value you got); whether something
> is callable [callable(x) -- far from ideal but often useful]; and
> whether something is (e.g.) indexable, sliceable, stringlike, numberish,
> by such code snippets as:
>     something[0]
>     something[0:0]
>     something + ''
>     something + 0
> sometimes in the try clause of a try/except statement if you want to
> emit very specific diagnostics in case of failure (but often just
> letting the resulting exception, if any, propagate, is best).  The
> assert statement is a good way to demarcate "paranoia checks".
*nod*

> But almost invariably the RIGHT way to be paranoid is to check up
> on signatures (interface), NOT on types (implementation detail).
Which is why i ask questions. Untill very recently I've been known to
say; ' ... and can hardly code my way out of a paper bag.'
Well, i'm working on that.
I think i could get out a paper one now, but perhaps not the plastic.

Again Alex, thanks for the food for thought ... guess it's heading on
time for the python nushell book.