. Python 2.1 function attributes

[Jan Dries]

Roy Katz wrote:
> 
> Let's see it! petition! vote! who wants and who doesn't?  No more of this
> of this 'Benevolent Dictator' or 'Hey I've got a patch' garbage.  *vote*
> and make Python not the patcher's language, not my language, and not
> yours, but *our* language. Lechayim, people!
> 

Deciding upon what should go into a design and what shouldn't by voting
is a VERY BAD IDEA, because it leads to camels (no P*** pun intended). A
"camel" is a methaphor for the "design by committee" antipattern,
because a camel, as they say, is the concensus reached though a majority
of votes by a committee instructed to design a horse.

Take any serious book on design or software architecture, and you will
find they all stress the importance of conceptual integrity, and often
suggest identifying one single architect (call him a 'benevolent
dictator') to make the decisions on what should and what should not go
into the design. In large projects there may be a handful of others the
lead architect can delegate some decisions to. 

I doubt Python would have been the wonderful language it is today had it
not been for Guido's benevolent dictatorship, just as Linux wouldn't
have been Linux without Linus and just as St.-Paul's Cathedral in London
wouldn't have been so magnificent if it had been designed by votes
rather than Christopher Wren.

On the other hand, adding features just because someone has a patch for
it is just as bad an idea as adding features by vote. 

Still, adding features to a language is not necessarily bad, IMO, not
even if it means there then are more ways to do the same thing. Any
"for" can be written as a "while", "if a != b:" can be written as "if
not a == b:" and even the plain "print" statement (without >>) can
always be written in terms of "write()".

But as was already pointed out by Tim, Moshe and others in this thread,
features like "print >>" and function attributes offer "obvious, simple
and easy to understand" alternatives to more cumbersome constructions in
regularly encountered situations. Because of that I personally think
"print >>" was a usefull addition, and that function attributes will be
an equally good addition. 
Although I must admit the ">>" was perhaps ill-chosen, because it makes
people think it's an operator (as it is in C++) while in fact it's just
part of the syntax of the print statement. Perhaps if "print >> file,
something" were written as "print to file, something" there wouldn't be
so much controversy over it, even though it wouldn't be doing more or
less than it does today. Just as there'd been war if "import module as
m" had been implemented as "import module >> m".

Regards, 
Jan