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]

Philip,

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

Especially:

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

The answer is included within the standard library. On any Python command
prompt type:
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!

Nothing wrong with coding conventions of course unless you:

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

 

[Brandon J. Van Every]

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

Isn't that going to happen to any popular, ISO standard language? An ISO
standard, oddly enough, means that compiler vendors will compete to add
value to the standard. Having a language remain under the iron grip of 1
developer is both a blessing and a curse. Some things remain wonderfully
well controlled and coordinated; other things are suppressed according to
the idiosyncratic whim of the arch-developer.

FWIW this dilemma has had profound historical importance. It's the main
reason the Chinese didn't colonize and conquer the world, despite having a
61 year head start in maritime expansion. Isolationist agrarian Confucians
beat expansionist maritime Eunuchs in a civil war, then banned all the
shipping for 130 years. Europe, being composed of many competing powers who
would try new things to gain an advantage, cleaned up.

My point is that Python may someday grow beyond the notion of 'BDFL', as
heretical as that may sound.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."

 

[Ron]

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

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_modules # 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