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 <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -- http://mail.python.org/mailman/listinfo/python-list
