On Fri, Feb 11, 2011 at 4:13 PM, Steven D'Aprano <steve+comp.lang.pyt...@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? -- http://mail.python.org/mailman/listinfo/python-list