Class Browsers vs Static Types (Re: Inefficiency of __getattr__)

Mark Carroll carroll at cis.ohio-state.edu
Thu Oct 5 09:37:51 EDT 2000


In article <eVTC5.3518$q9.166701 at news-west.usenetserver.com>,
Kragen Sitaker <kragen at dnaco.net> wrote:
(snip)
>Those features are buggy and poorly designed, unless --- and probably

They fit snugly in with the rest of everything. What makes you think
they're any more poorly designed than a later first attempt would have
been?

>even if --- you've implemented something very similar before.  And when
>you do get around to using them, you will end up fixing bugs that you
>wrote months before instead of minutes before.  This makes the problem
>much harder.

IME it is easier to fix bugs in old code than to add substantial new
features to old code - after all, it was written at a time when you
understood the rest of that part better so even if you got an interaction
with it wrong then at least you have some piece of code that _tries_ to do
the interaction and reminds you it needs to be done at all. No doubt one's
mileage varies:

(snip)
>and fixing them; it vitiates process feedback.  (Do you write most of
>your bugs when working past 17:00?  When you've eaten a low-protein
>lunch?  How effective are your code reviews?  How will you have any
>idea if your bugs remain hidden for a month?)  When you're working in a
>system full of untested code and something breaks, you can't tell if
>it's something you just added --- or a bug that's been there for weeks,
>months, or years.  That makes debugging slower.
(snip)

When you add code that actually uses a feature, and a bug appears, you can
be pretty sure the bug's in the feature or the bit of code that calls it.
No different to if you'd added it later.

-- Mark



More information about the Python-list mailing list