Life of Python

[Alan Gauld]

"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
value of
> "large") you have to discipline yourself to write well
structured code.

As always.

> 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.
Why not just define a class with a set of unimplemented methods.
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.

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

> this should be expanded further, i.e. more build-in decorators
for
> interfaces, abstract classes, parameter and return value
restrictions.

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.

> with Perl than with Python and since there is no way of forcing
a
> programmer to do it a certain way,

I'm always uncomfortable about trying to "force" a programmer
to do it a certain way. I can never know what circumstances
those client programmers might be facing when I write/design my
code. And I can never be sure that I know better than the
client programmer.

I've seen too much C++ code that begins

#define private public

to believe that trying to force programmers rather than inform
them is a good idea.

(And FWIW I have worked on several multi million line projects
with upwards of 400 programmers working in 5 or more locatons
in Lisp, C, SQL, COBOL etc. Attempts to impose rules rather
than agreed protocols have never been very helpful in my
experience)

> its often easyer to rewrite Perl programs over 400 lines

That probably has a lot more to do with Perl's inscrutable
syntax and "many ways to do it" approach than any of the
classifiers being discussed here! I certainly didn't find
us rewriting Lisp code rather than enhancing what was there,
and Lisp shares much of Python's approach to life.


-- 
Alan G
Author of the Learn to Program web tutor
http://www.freenetpages.co.uk/hp/alan.gauld