does python have useless destructors?

[David Turner]

Peter Hansen <peter at engcorp.com> wrote in message news:<htudnXIw-_HkalPdRVn-gQ at powergate.ca>...
> David Turner wrote:
> > 
> > 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

Very rarely do I do whole-program analysis.  I don't know anyone who
does that either.  What I'm talking about are small chunks of code
with critical behaviour.  The mutex example I gave is a case in point.
 I can prove, under a reasonable set of assumptions, that there is no
use-case that will lead to incorrect behaviour.  This is far more
difficult in Python as I have to do the proof each time I use the
object.  This is why formal proofs are rare in the industry - they
just become too complicated.


> 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...

I don't have a gun to my head.  But I do have direct financial
liability, which is just as good :-).


> Also interesting.  Have you actually tried using Python for big
> systems with multiple programmers, and encountered serious problems?

Admittedly I have not.  I mostly use it to glue things together, in
which area it excels.


> 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.

Interesting.  I must say I'm a little envious :-).


> 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...  ;-)

I don't see how the "obviously" bit follows.  But I will say that I
know of almost no software makers out there that use C++ "properly". 
99% of the code I've seen out there is "C with classes".  I'd be happy
to discuss my views on what constitutes "proper" use of C++, but this
is not the forum for that :-).


> 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...

I agree.  Not much point in getting into an argument over that :-). 
But the two approaches are not necessarily mutually exclusive:- some
bits of the program (read libraries) require careful thought and
design before a line of code is written; other bits (read purposive
code) do better in a test-driven environment.

My "other bits" tend to be a tiny fraction of the whole, so please
excuse me if I exhibit some bias towards top-down development ;-).

Regards
David Turner