Re: does python have useless destructors?

From: Peter Hansen (peter_at_engcorp.com)
Date: 06/15/04 

Date: Tue, 15 Jun 2004 09:19:52 -0400

David Turner wrote:

> Peter Hansen <peter@engcorp.com> wrote in message news:<auqdneR-tKpSXlDdRVn-uQ@powergate.ca>...
>>David Turner wrote:
>>>I *want* to spend more time in Python, but as things stand my C++ code
>>>is more robust.
>>
>>Is this a theoretical definition of "robust", or a practical one?
>
> I mean that it's very much easier for me to write provably correct
> code in C++. Trying to do the same in Python is an uphill struggle.

Interesting... when was the last time you proved that your C++
program was correct? Honestly. I've *never* seen anyone prove
a program was correct, especially not C++, though I know that
some folks do seem to want to do that, and they apparently
actually do in some environments. I'm just surprised to find
anyone here who actually writes the kind of code that must have
formal proofs done for it before it can be used...

> Furthermore, the C++ version is far more maintainable; the coding
> style is *intentional*. For big systems with multiple programmers
> using each other's objects, there's no question that I'd use C++.

Also interesting. Have you actually tried using Python for big
systems with multiple programmers, and encountered serious problems?
I have just recently left a company where we had at least twenty
man-years invested in one large Python system, with as many as about
six Python programmers working on it simultaneously. I can say
uncategorically that the software is the most stable and robust that
I've ever been involved in writing. Any C, C++, Delphi, or Java
system in which I was previously involved was definitely less robust.

Since it's therefore obviously not a property of these languages
that they are robust or not, it must be something more to do with
the programmers, or the process, or something. I guess... ;-)

> Of course, for small projects, Python is miles ahead of C++. I'd like
> to see that advantage extended to large projects as well. I hope that
> the complications involved in writing C++ code are accidental rather
> than inherent qualities of a big-system language.

I would say those complications are not inherent, and my experience
with Python (where we had few such complications) bears out that idea.

> "...in any way related to Python's destructor behaviour" is the key
> part here. Python programs don't fail so much as misbehave. If they
> don't misbehave (and they're doing anything complicated), the code is
> often nested several layers deep in try/finally blocks. It's ugly,
> and hard to maintain.

I don't think code with multiple layers of nested try/finally and
such is well-written. It should likely be refactored so that more
methods are used, so that the code has greater cohesion and lower
coupling. Two levels deep is probably the max I would consider
without examining the structure very closely and considering
refactoring.

> In my experience, the main reason for this is that the onus is on the
> user of the API to use it correctly. The most trivial examples of
> this are acquire/release cycles in things like mutexes. There are too
> many ways in which a user can fail to release a mutex, either through
> forgetfulness, or through not considering all possible paths of
> execution (which is difficult to do!). Now, interface contracts can
> remind the user when he needs to do something, and help to trace a
> fault, but they don't necessarily make the user's job any easier (or
> quicker). The C++ community, on the other hand, is working towards
> ways of *enforcing* API contracts, by reworking the API in such a way
> that it can't be abused.

Sounds like two worlds here. We didn't need contracts or enforcement
of this kind. Our developers were working test-first, with as wide
coverage of unit tests as possible, so we already knew the code was
going to be pretty good without getting into B&D like that. I can
see you have not adopted the XP mentality and test-driven development,
so our thoughts on this whole matter are inevitably going to be
contrary...

-Peter

Relevant Pages

  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... with enforcing that "shouldn't" in the language itself? ... In Python, direct access to pointers is a MUST NOT. ... where you are allowed to mess with the implementation. ... human assembly language programmers? ...
    (comp.lang.python)
  • Re: Is classless worth consideration
    ... > The problem we Python programmers are having is understanding the ... Python itself but in the "we Python programmers". ... specialmethod init ...
    (comp.lang.python)
  • Re: How to organize Python files in a (relatively) big project
    ... storing your scripts without the problem of breaking the import statements. ... Python script it must reach before you split it into two separate files, ... management system can really help in anticipating it at that point. ... > like the advice of more experienced python programmers. ...
    (comp.lang.python)
  • A Pythonic Way to Measure and Improve Your Programming Skills?
    ... Those who know me know I am no fan of the programmer certification industry and I agree that your typical certificate arrangement, e.g. to show HR to get that box checked in your candidate file, so a company can skip responsibility in vetting a candidate, is un-Pythonic. ... However, I do think we need a good answer to the engineering manager or team leader who asks, "how do I know this person knows Python?", and to the candidate who thinks, "I believe I'm good at Python but am I as good as I think?". ... We all run into or are programmers who think they are hot-stuff, especially those of us who work solo as many in our community do, but when put side-by-side against others, fall a bit short. ...
    (comp.lang.python)
  • Re: An Editor that Skips to the End of a Def
    ... You definitely used the wrong languages:) ... | having one operation per line, programmers ... I demand a Python module implementing this, ... Would you accept that the style of editing is a matter of taste? ...
    (comp.lang.python)