Guido at Google

[Thomas Wouters]

On Thu, 22 Dec 2005 19:38:12 +0200, Ilias Lazaridis wrote:

> As expressed above, I am afraid about pythons evolution-speed and futher 
>   evolution in general.

Yet you don't seem to be worried for any (Python) specific reason. Python
evolution has known its ups and downs. For instance, back when Guido
worked at CNRI, Guido was one of the few people with direct access to the
CVS repository. The others were, I believe, all CNRI employees (and
trusted Python developers.) This worked fine for quite a bit, since Guido
first did most of the work, and reviewed patches from the community
personally. Towards the end of Guido's employment with CNRI, this had
begun to chafe a bit, and if you look at releasedates and featuresets,
you'll see quite a gap between Python 1.5.2 and Python 2.0. (Python 1.6
doesn't really count, for various historical reasons, but even if you
compare CNRI-funded 1.6 with opensource-developed 2.0 you'll see a large
set of diverse new features.)

What happened was that Python development moved to SourceForge, and more
people got easier access. More trusted developers got write access to the
repository, and more people got involved in writing patches. It also meant
Guido couldn't keep up with development by others, and he (eventually)
solved that by introducing PEPs. (Like much of Python, he probably
wasn't the first to voice the suggestion, but it's quite likely he was
in fact thinking of it, possibly subconciously, before anyone suggested
it...[1] So I don't think whoever voiced it first minds Guido getting the
crdits.) But he didn't think of PEPs before they'd become absolutely
necessary. He didn't sit at CNRI thinking, "Gee, I wish I could give more
people access and accept more community patches, but how do I decide which
ideas are fundamentally good or bad?", then thought up the administrative
layer of PEPs. They showed up when they were needed, in a form that seemed
convenient, and they evolved over time (slowly, and only slightly, as far
as I can tell) to fit the specific needs. The tools to facilitate
evolution grow from necessity. They probably wouldn't work if forced upon
Python.

And the evolution speed in general, regardless of tools that make that
evolution easier, is in fact determined by need. The unification of
types and classes grew out of a need. It was quite a fundamental step in
Python's object model, and one that had been argued long before it
happened, but the actual implementation waited, in my eyes, until exactly
the right time. Obvious practical need for it, good ideas with regards to
implementation, experience from Zope's ExtensionClass and various uses of
the old metaclass hook, and a group of Python programmers quite eager to
play with all the new toys Guido gave them. Heck, I still love playing
with new=style classes and creating subclassable types and subtypes in C.
A few years earlier it wouldn't have ended up the same, for lack of
experience and need, and a few years later would probably have been too
late.

> a) Missing clear and concise documentation, e.g. of Python Object Model, 
> like UML diagramm:

I guess it depends on your idea of clear and concise. I've never, ever,
had a problem with understanding Python's object model. Even new-style
classes only required two PEPs, a few hundred lines each, for me to
understand. I honestly don't care about UML diagrams. And, what's more,
apparently neither does anyone else, or the diagram would have been made
already. In fact, if it's missing, why don't you add it? That's what
opensource is about :)

> b) Leadership (Board/Leader) should engourage change suggestions and 
> analytical feedback, whilst accepting "analyst-role" in addition to 
> "implementors-roles" (_both_ are contributions! This should be 
> communicated by the Board/Leader to the Communicty):

Why would that be necessary, if the current system works? Extra layers for
the sake of extra layers, bureaucracy to feed the need for bureaucracy in
itself, seems madness to me. If it ain't broken, don't fix it. I'm sure
the extra formal layers work quite well in other projects, in other
communities, just like the Python setup wouldn't work for those other
projects. But it works for Python, as evidenced by Python's evolution
speed.

> c) I mean, when will python become _really_ fully Object-Oriented, with 
> a clean reflective Meta-Model?

When someone needs it enough to convince Guido it's practical. Python
values practicality above quite a lot of things, like consistency.
Consistency for the sake of consistency, by giving up practicality,
ease-of-use, readability, portability or any of the other important
aspects of Python, will hopefully never happen.

>> and why should we listen?
> Cause this would increase the evolution-speed of python.
> This would contribute to its success.

I don't understand where your confidence in these matters comes from.
The 'this' you refer to *might*, in fact, increase the evolution-speed,
although at what cost I am uncertain. I wouldn't be surprised if it cost
Python, or the Python community, its soul. There are a great many people
who think Python is already evolving at quite a high speed, and would
rather see it slow down than speed up. I am almost, but not quite, in that
camp; I think Python is nigh perfect as it is, but I have enormous respect
for the active Python developers, who by and large are insanely smart
people, and I can't but love and be terribly excited with everything they
think up next. And they're friendly people, to boot.

A higher evolution *might* contribute to Python's success. It may also
contribute to its downfall. Forcing an open-source community to do
something it doesn't want to do will *certainly* lead to its downfall.

Spam-spam-spam'ly y'rs,

[1] Either that, or Guido used the time machine to go back and change his
mind. Or everyone else's.
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!