Life of Python

[Chris Lambacher]

On the accessor function topic.  Here is a good description of why you
don't need accessors in python (among other things) written by the
main PEAK(http://peak.telecommunity.com/) developer (Phillip J. Eby):
http://dirtsimple.org/2004/12/python-is-not-java.html

Some other useful articles in a similar vein:
http://dirtsimple.org/2004/12/java-is-not-python-either.html
http://naeblis.cx/rtomayko/2004/12/15/the-static-method-thing

Phillip has written several very interesting python related articles
on his blog (dirtsimple.org).  Also PEAK and the spin off pyprotocols
have a lot of very interesting tools for helping to manage large
python projects.

-Chris

On 6/25/05, Benji York <benji at benjiyork.com> wrote:
> Uwe Mayer wrote:
> > con: If you are planning larger applications (for a reasonable value of
> > "large") you have to discipline yourself to write well structured code.
> 
> This is definitely true, no matter the language you use.
> 
> > Then you will want to specify interfaces,
> 
> If you're really interested in interfaces you might want to check out
> Zope3.  Even if you don't want to use the "web" parts, the component
> architecture parts (interfaces, adapters, etc.) might be interesting to you.
> 
> In a related vein is PEAK (http://peak.telecommunity.com/).  It also has
> some related ideas about interfaces, components, adapters, etc.
> 
> > accessor functions with different read /write access, ...
> 
> I don't quite follow here.  Are you talking about using a method like
> "thing.getX" instead of just accessing the attribute directly like
> "thing.x"?  If so, that kind of up-front design isn't necessary in Python.
> 
> > Unless you have designed the software interactions completely bevorehand
> > (which never works out) this is the only way to incorporate changes without
> > refactoring your source all the time.
> 
> Refactoring *is* the way you handle not being able to "[design] the
> software interactions completely bevorehand".
> --
> Benji York
> --
> http://mail.python.org/mailman/listinfo/python-list
> 


-- 
Christopher Lambacher
lambacck at computer.org