ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> python-list
python-list
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

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved