Thanks and kudos to Python core team (was Re: Booleans, integer division,backwards compatibility; where is Python going?)

Lumberjack lumber at jack.com
Thu Apr 11 00:56:55 EDT 2002


Peter Hansen <peter at engcorp.com> wrote:
> I'm dismayed by comments attacking the core developers when made
> by people who have not contributed more than I or my team have.
> Beggars can't be choosers, and nobody likes a whiner...

This incorrectly labeled "troll" has made small monetary and other 
contributions to the advancement of Python. And a larger investment in 
using the language.

I'd hate to see that investment thrown away over a failure by the core 
developers to recognize the normally undeniable evidence that a never-
ending flow of frequent PEPs and changes to the language will undermine the 
legitimacy of Python in a host of obvious and not so obvious ways. Change 
isn't synonymous with progress; changing your underwear every day isn't 
progress (well, for anyone doing it on a weekly basis I guess it would be).
These maxims or precepts should be kept in mind:

1) One should have a well defined set of prioritized requirements and a 
recognizable goal. Saying you are designing the "perfect language" isn't a 
requirement or a goal; it is meaningless and not measurable. Nor is saying 
it should be easy for nonprogrammers. If you don't have a well defined idea 
of your goal, you are never going to know when you've arrived or how to get 
there.

2) One shouldn't ask "is there any compelling reason not to make this 
change" but rather "are there any compelling reasons with good supporting 
evidence that justify making this change?" Quite a different thing indeed. 
And the minor release strategy doesn't yield evidence since no one is doing 
any data collection to measure the success of the changes, and even if they 
were, the goal of backward compatibility would be in conflict with the need 
to remove failed changes from the language.

3) Changes should be much much less frequent, and previously minor release 
changes should be incorporated into the major releases. People had no 
choice in accepting Python at the start; it was a take-it or leave-it 
issue. The psychological impact was focussed, not dragged out for a long 
period of time. There are also commercial reasons for minimizing the 
frequency of changes. Frequent minor releases telegraph indecision and lack 
of discipline.



More information about the Python-list mailing list