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