Life of Python

[Terry Hancock]

On Monday 27 June 2005 02:34 am, Alan Gauld wrote:
> "Uwe Mayer" <merkosh at hadiko.de> wrote in message
> news:d9jcij$nm6$1 at news2.rz.uni-karlsruhe.de...
> > con: If you are planning larger applications (for a reasonable
> > [...]
> > Then you will want to specify interfaces, accessor functions
> with different
> > read /write access, ...
> 
> Why? What advantage does this really give you over indicative
> doc strings? interfaces in particular are a modern madness.

Interfaces, IMHO are best viewed as documentation.  I have used
the Zope 3 interfaces module, and I think it's going to be very
useful to me.  Although, theoretically, you could do all of this
with doc strings, being able to check that you've documented
everything that should be (including methods and attributes).

With interfaces, you distribute the docstrings over the class. Also,
the interpreter helps you with documentation problems, because
standardized means are used to represent what methods expect
as arguments, and so on.  They don't really force you to do it that
way, but they generally catch broken attempts to implement the
interface.

> Why not just define a class with a set of unimplemented methods.

Takes too much time, and gets mixed in with functionality.
Basically, it's more boilerplate than the better interface modules
written for Python.

> Who cares if someone tries to instantiate it? What can they do
> with it? They only make sense in languages which are statically
> typed and rely on inheritance to implement polymorphism.

> Pure accessor methods are usually a mistake anyway, but can
> be done using properties if you really must.

Yes -- there's just no reason to do that in Python.  Properties mean
you don't have to worry about an attribute changing into a method,
so there's no reason to try to "preempt the damage".  No damage,
so no preemption needed.  I personally, really prefer attributes (or
properties) over explicit get/set methods.

> > 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.
> 
> On really big projects it is fairly normal to define the
> structure of the code to quite a detailed level - often
> using Case tools and UML etc - so refactoring is only needed
> when you discover a hole. Thats true regardless of size of
> project but the Case approach tends to limit the damage.

Okay. This makes sense if the software is:

1) Designed by one institution.
2) Designed almost entirely before deployment.
3) Not designed to be worked on by users and
    semi-trained developers.

In other words --- proprietary software.

For a free-software application, in which you want to maximize
your collaborative advantage, you want to make one-sided
cooperation as easy as possible.  I do not *know* who my
collaborators will be.  They may well not be privy to UML diagrams
and CASE tools I may have used.  Certainly a lot of them wouldn't
bother to look if they could avoid it.  OTOH, a well-defined
set of interfaces shows them where they can make clean breaks
in the design in order to localize what they need to learn and
what they need to fix -- and it's all right there in the source code.

It's just like fixing an old house. The biggest problem is knowing
where to stop --- how much of that plumbing do you want to
take out and rework?  If it has cutoff valves and unions in the
right places, it will come apart in sections and you have a much
better chance of fixing it without getting into an intractable mess.
Software interfaces can be used to the same effect --- making the
job easier for the next person who comes along.

If you are trying to trade on a free-software advantage, then it is
absolutely in your best interest to make the way as easy as
possible for the people who follow you.
 
> > this should be expanded further, i.e. more build-in decorators
> for
> > interfaces, abstract classes, parameter and return value
> restrictions.

Specifically, *I* would like one of the available interface
implementations to find its way into the standard library. Obviously,
*my* life would be easier if it's the Zope 3 implementation, but I'll
learn to use whatever gets in there.

> What kind of parameter and return value restrictions?
> In a dynamically typed language there is a limit to what can
> be applied, and much of that is of limited value IMHO.

Yes, there is a limit, and it's madness to go beyond it. But there
is a useful middle ground.  For example, it is quite useful to
specify that an argument of a method should expect an object
which implements a given interface. For simple objects, this is
usually handled by things in the interface module.  A method
which expects a number may check that the object has __add__,
__mul__, etc.

But the real win is when it's supposed to be a much more
elaborate object defined by the application.

Intelligent use, of course, will suggest many cases where constraint
is unnecessary boilerplate.  But there are other situations where
it's useful.

> > with Perl than with Python and since there is no way of forcing
> 
> I'm always uncomfortable about trying to "force" a programmer
> to do it a certain way. 
> [...]
> to believe that trying to force programmers rather than inform
> them is a good idea.

Yeah, IMHO, the Python way is to *suggest*, not *force*.  I generally
would consider it good style to provide test code that the application
programmer can use to check out their classes during development.

Of course, one of the points of this is that Python *does* provide
these abilities, in contrast to what the OP said.  They may not look
quite like they do in Java, and they may not seem as "tough". But,
IMHO, they are "tough enough".

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com