Re: python development practices?
by Peter Wang other posts by this author
Oct 31 2001 4:28PM messages near this date
Re: python development practices?
|
Re: python development practices?
just as an initial comment, i think this is about the most
sensible/meaningful answer i've seen to my question so far...
On Tue, 30 Oct 2001 20:58:56 -0800 (PST), <brueckd@[...].com> wrote:
> > as an aside, and i don't mean to sound obnoxious, but why did guido
> > not put in data hiding into python at an earlier stage? my colleague
> > whose background on generic programming comes entirely from the STL
> > points this "wart" out as one of python's largest, and brings up the
> > good point that data hiding was well known to the OOP world at the
> > time of python's first incarnations.
>
> "Well known" != "Always a Good Thing". Curly braces were also well-known
> then too, and I'm very glad Guido chose against using them. :)
ditto. i realized a while back that tab indentation is ultimately an
enforcement of the Don't Repeat Yourself principle. *all* good human
programmers indent code blocks, and to require delimiters for ease of
parsing is just duplicating that structural information to the
compiler. duplication = source of bugs. there is really no simpler
argument in favor of tabs.
> A better approach is to cater to mature programmers and to use processes
> that help other programmers mature too. A few places I've worked have used
> something like the following (and these work well for non-Python code
> too) and they really helped me:
----snip----
> We've used these guidelines and have had very few problems that you'd
> consider related to "data-hiding". When breakage occurs, we go look at the
> unittests (including the previous versions if needed) and compare it to
> the code that broke. If breakage is due to the library maintainer changing
> the documented use and behavior of the code, it's the maintainer's
> responsibility to fix the problem, provide a good upgrade path, etc.
this is a good approach. the crux of the approach you outlined -
using unit tests as the primary API documentation - is really the sort
of answer i was looking for. are there other, perhaps python-specific
practices which have worked well?
> Like I said, these worked for me and really helped me become more
> disciplined.
thanks for the info.
-peter
--
http://mail.python.org/mailman/listinfo/python-list
Thread:
Peter Wang
Peter Hansen
Toby Dickenson
Tim Peters
Steve Holden
Steve Holden
Cliff Wells
Tim Peters
Martijn Faassen
Cliff Wells
Cliff Wells
Martijn Faassen
Martijn Faassen
Paul Rubin
Russell E. Owen
Barry A. Warsaw
Martijn Faassen
Peter Wang
Skip Montanaro
John Roth
David Bolen
Peter Wang
Peter Wang
Skip Montanaro
Chris Tavares
Darren Collins
David Bolen
Paul Rubin
Paul Rubin
Peter Wang
F Basegmez
Richard Jones
Richard Jones
Neal Norwitz
Graham Ashton
Peter Wang
Russell E. Owen
Skip Montanaro
Cliff Wells
Hung Jung Lu
Wade Leftwich
Peter Wang
Peter Wang
Peter Wang
Chris Gonnerman
Paul Rubin
Andrew Dalke
Paul Rubin
Luigi Ballabio
Paul Rubin
Tim Peters
John Roth
Paul Rubin
Richard Jones
|