Life of Python

[Uwe Mayer]

Hi,

I have come across the following statement a number of times:

http://mail.python.org/pipermail/python-list/2003-July/171805.html
[... how to enforce pure abstract class ...]
> Python, in general, doesn't try to stop the programmer doing things, the
> way many other languages do.  This is known in the community as the
> "we're all consenting adults" philosophy.

I have a split opinion on that: 

pro: If you're writing smaller apps and everything stays rather clearly laid
out you don't need to care about abstract, virtual, accessor functions,
private, public, interfaces, etc

con: If you are planning larger applications (for a reasonable value of
"large") you have to discipline yourself to write well structured code.
Then you will want to specify interfaces, accessor functions with different
read /write access, ...
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.

Therefore I come to the conclusion that a general purpose language like
Python may well allow tampering with name-mangeling, dynamic method
resolution, whatever, BUT it should also provide facilities to allow
enforcing a more structured approach.

This is why I welcome i.e. the decorator support in Python 2.4. And I think
this should be expanded further, i.e. more build-in decorators for
interfaces, abstract classes, parameter and return value restrictions.
You can, but you must not; and I use both, depending on the project I'm
working on.

IMO this is a problem i.e. Perl is faceing: you can do even more rubbish
with Perl than with Python and since there is no way of forcing a
programmer to do it a certain way, its often easyer to rewrite Perl
programs over 400 lines than to fix them.

Ciao
Uwe