Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

"Chris Mellon" <arkanes at gmail.com> writes:

>> On the other hand, in Python, you can be 100% sure that your files
>> will be closed in a timely manner without explicitly closing them, as
>> long as you are safe in making certain assumptions about how your code
>> will be used.  Such assumptions are called "preconditions", which are
>> an understood notion in software engineering and by me when I write
>> software.

> Next time theres one of those "software development isn't really
> engineering" debates going on I'm sure that we'll be able to settle
> the argument by pointing out that relying on *explicitly* unreliable
> implementation details is defined as "engineering" by some people.

The proof of the pudding is in it's eating.  I've worked on very large
programs that exhibited very few bugs, and ran flawlessly for many
years.  One managed the memory remotely of a space telescope, and the
code was pretty tricky.  I was sure when writing the code that there
would be a number of obscure bugs that I would end up having to pull
my hair out debugging, but it's been running flawlessly for more than
a decade now, without require nearly any debugging at all.

Engineering to a large degree is knowing where to dedicate your
efforts.  If you dedicate them to where they are not needed, then you
have less time to dedicate them to where they truly are.

|>oug