Class or Dictionary?

[Dan Stromberg]

On Fri, Feb 11, 2011 at 4:13 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 11 Feb 2011 10:15:27 -0800, Dan Stromberg wrote:
>
>
>> I'd use a class rather than a dictionary - because with a class, pylint
>> (and perhaps PyChecker and pyflakes?) should be able to detect typos
>> upfront.
>
> *Some* typos. Certainly not all.

The salient bit is not that all typos are (or are not) caught, but
that significantly more typos are caught before they cause a blowup in
production.

> The more complex the code -- and with 100 or so parameters, this sounds
> pretty damn complex -- there is a non-negligible risk of mistakenly using
> the wrong name. Unless pylint now has a "do what I mean, not what I say"
> mode, it can't save you from typos like this:
>
> params.employerID = 23
> params.employeeID = 42
> # much later
> if params.employeeID == 23:
>    # Oops, I meant employ*er*ID
>    ...

No, and yes, and no.

1) No: Pylint can frequently catch variables that are used before they
are set or set but never used
2) Yes: If you write the wrong variable, and it is read somewhere
afterward, you've still got a typo that's essentially a logic bug in
how it manifests
3) No: You should not use variable names that differ by only a single
character, or are too easy to "thinko" for each other - EG it's better
to use params.companyID, params.supervisorID and params.workerID;
these are clearly distinct.

>> With a dictionary, typos remain runtime timebombs.
>
> Are your unit tests broken? You should fix that and not rely on just
> pylint to detect bugs. Unit tests will help protect you against many more
> bugs than just typos.

Unit tests do not replace static analysis; they are complementary techniques.

I started out in the manifestly-typed world.  Then I moved into mostly
python and bash, without any sort of static analysis, and loved it.
More recently, I've been using python with static analysis, and I've
been wondering why I lived without for so long.  That doesn't imply a
rejection of duck typing - it merely means I don't want my code
embarrassing me unnecessarily (though I confess, I find Haskell and
the ML family very interesting for their static, _inferred_ typing).

It's a rare program of much size that can be tested so thoroughly that
static analysis is 100% obviated - especially in the reporting of
error conditions.  An accidental traceback when you're trying to
output an important detail related to one of a few thousand error
conditions is embarrassing, and frequently could be prevented with
pylint.

Also, pylint tends to run much faster than the large battery of
automated tests I prefer to set up.  IOW, it can quickly catch many
kinds of trivial blunders before incurring the development-time
expense of running the full test suite.

> Besides, and I quote...
>
> "I find it amusing when novice programmers believe their main job is
> preventing programs from crashing. ... More experienced programmers
> realize that correct code is great, code that crashes could use
> improvement, but incorrect code that doesn't crash is a horrible
> nightmare." -- Chris Smith

LOL.  Irrespective of some crashes being beneficial, the fact remains
that easily avoided, nonessential crashes should be avoided.  Pylint
enables this to be done for an important class of errors.  To
eliminate them quickly and painlessly isn't precisely an attribute of
a novice.

Did you have some sort of bad experience with pylint?  Do you resent
the 20 minutes it takes to set it up?