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

[Alex Martelli]

David Broadwell wrote:
   ...
>> 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.

Strings are peculiarly troublesome, because they're intrinsically
"sequences" BUT more often than not you in fact want to treat them
as "scalars" instead.  Again, this applies to instances of str,
unicode, UserString, and possibly other string-ish types too (such
as mmap).  However, if you extract the bound methods you need as I
later suggest (e.g. append and sort, or whatever it IS that you do
need to call), you may be able to 'catch' strings just as well as
any other stray type -- few types would have append and sort methods
unless in a deliberate attempt to mimic lists, after all.


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

Sure, but programmers who have survived a few decades in the trenches
(inevitably including some occasions of having to maintain code written
by a team of monkeys randomly banging on terminal trees AND having had
one's code 'enhanced' by the same team) do tend to develop similarly
defensive attitudes, even if they've never faced an actual 'adversary'
actively trying to subvert their code but 'just' unintentional blunders
by a well-meaning clue-deprived colleague (including -- oneself:-).

The key is to be paranoid in clever ways -- checking what's cheap to
check and will catch many potential problems without damaging your
software's usefulness.  Like most programmers I've done some occasional
amateurish stints at sysadm'ing and marveled at the way a REAL sysadm
would often zero in on the root of a weird, "impossible" problem (on
the basis of their experience, clever paranoia, etc) -- reciprocating
on occasion by doing some of my own 'zeroing in' (e.g. on subtle bugs
in a sh or awk script -- and even some perl, when THAT took over:-).

The skill sets aren't ALL that different, deep down, IMHO.


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

Super!  It really IS simpler than it may sound.  I'm sure you'll
catch up on this in no time flat.


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

QOTW +1 !-)


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

You're most welcome!  And, I would suggest, have a look at the Cookbook
too, both the free online version and the printed O'Reilly one: it does
not delve into the language rules &c all that much, but it does provide
examples and (in the printed version) substantial explanation of how
and why things work.  Some people FAR prefer that from the necessarily
more concise style of the Nutshell -- where I do give rules and advice
but rarely get the chance to explain in depth WHY a rule or guideline
is the way it is...!-)


Alex