Beware complexity

[Philip Smith]

I wonder if anyone has any thoughts not on where Python should go but where
it should stop?

One of the faults with langauges like C++ was that so many new
features/constructs were added that it became a nightmare right from the
design stage of a piece of software deciding which of the almost infinite
different ways to do the same thing to use.

Result: the development of various coding standards (essentially definitions
of what 'safe subset' of the language you intended to use in all your
projects) to 'cripple' the overly complex language.

Conventions on type conversion are just one example. Without using strict
coding conventions the richness of the language could, and often did, result
in ambiguity. In my experience too C++ has defeated its own object (eg
portability) - I've given up in many cases trying to compile third party
libraries because I don't have the time to collect every version of every
compiler for every platform in existence which is what C++ seems to demand
(particularly if you are trying to cross-compile Unix->Windows).

Nothing wrong with coding conventions of course unless you:

a) Want to read and understand other peoples code
b) Want your code to work with it

There probably isn't a language in existence that provably constrains a
programmer to use one and only one 'top level' approach to code a particular
'class' of problem but Python does seem to have a way of naturally
'suggesting' this through its very simplicity.

It seems to me that from here on in the Python developers should be very
careful about adding new features to a language which (subjectively) already
seems capable of handling pretty much any 'class' of problem. There is
plenty of scope left of course for continuing to develop libraries and
optimize performance.

[Harald Massa]

Re: Beware complexity

Philip,

more often than not, all needed was included in Python years ago.

Especially:
[color=blue]
> I wonder if anyone has any thoughts not on where Python should go but
> where it should stop?[/color]

The answer is included within the standard library. On any Python command
prompt type:
[color=blue][color=green][color=darkred]
>>>import this[/color][/color][/color]
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
[color=blue]
> Nothing wrong with coding conventions of course unless you:[/color]

So "coding conventions" are more or less rendered as something of ancient
times; Python has its Zen. (of course, as I said, included in the
standard library)

And: the fear that Python gets extended over sensible bounds maybe real.
But: Just have a look within python.devel, what happens on any (pun
intended) extension to builtins: It's a gentle and polite, nontheless
strong and hard discussion; a real evolutionary survival test.

Python is a healthy tree: it grows. But Guido and the Bots are
thoughtfull gardeneres: they are not afraid to cut bad branches.

Harald

[Ron]

Re: Beware complexity

Philip Smith wrote:
[color=blue]
> I wonder if anyone has any thoughts not on where Python should go but where
> it should stop?[/color]

My feelings on this is, it's a problem of organization and
documentation. Do both of these well, and things will be manageable.

I would like to see a bit cleaner file organization framework. I think
keeping the different parts/modules/utilities/etc. Seperate and in
their own place would solve a lot of distribution/installation problems.

Having a central distribution place for people to download third party
modules in a standard install/uninstall package format would also help.

# Example directory structure.
python24
main
core # interpreter, dll's, and min.
tools # test scripts
examples
docs
standard_module s # modules included in distribution
module name
core # standard module dlls
tools
examples
docs
next module name
core
tools
examples
docs
<etc>
extend_modules # 3rd party extension modules
"module name"
core # dlls
tools # helpfull scripts
examples
docs
<etc>
tools
idle
core
tools
examples
docs
py2exe
core
tools
examples
docs
document_reader
# script to read and search all doc files
# and run related examples scripts.
core
tools
examples
docs


Ron