Guido at Google

[JB]

It seems that our master Guido van Rossum had an offer from google and
he accepted it!!

long life to Guido & Goole ! many things to come ;)

ju²

[Bengt Richter]

On Thu, 22 Dec 2005 09:07:26 -0800, al***@mail.comc ast.net (Alex Martelli) wrote:

Renato <re************ @gmail.com> wrote:

all of the native administration tools of RedHat (all versions) and
Fedora Core are written in python (system-config-* and/or
redhat-config-* ). And even more importantly, yum (the official
software package manager for Fedora and RHEL) and Anaconda (OS
installer) are written in Python, too.

BTW, Chip Turner (from RedHat, and deeply involved in those
developments ) happened to start at Google the same day I did;-).

So is google about to determine how many luminaries can fit on the head of a project? ;-)
Seriously, if you heavies do sometimes work on the same project, it would be
interesting to know what modes of co-operation you tend to adopt.

Regards,
Bengt Richter

[Nicola Musatti]

Alex Martelli wrote:

Renato <re************ @gmail.com> wrote:

all of the native administration tools of RedHat (all versions) and
Fedora Core are written in python (system-config-* and/or
redhat-config-* ). And even more importantly, yum (the official
software package manager for Fedora and RHEL) and Anaconda (OS
installer) are written in Python, too.

BTW, Chip Turner (from RedHat, and deeply involved in those
developments) happened to start at Google the same day I did;-).

Ah, the closed source days! Back then you could just buy the company
and be done with it. Now you have to chase developers one by one all
over the world... ;-)

Cheers,
Nicola Musatti

[EP]

rbt wrote:

Luis M. González wrote:

Java => Sun
.Net => Microsoft
C# => Microsoft
Linux => too many big name IT companies to mention
Python => ________ ?

I know at least one company responsible for a linux distro (Cannonical
- Ubuntu), which encourages and even pays programmers for developing
application s in Python.
His founder, Mark Shuttleworth, is a python fan.

Aren't most all intelligent people Python fans?

Sure, but I am not under the illusion that intelligent people control
the fate of the world
Python is so unbarbaric or one might say 'refined', yet it can be
applied in a practical manner to all sorts of things. It's like having
James Bond as your very own personal body guard ;)

The truth becomes evident: Guido did not invent Python, Q did!

Or is Guido Q?

Reminds me of a story I heard about Guido- he was working at the PSU and

[drew.smathers]

And I have around one year to wait for Ruby to get rid of the nasty
syntax copied from Perl and make it look as beautiful as Python ....
Then I'll consider switching. ;)

Ummm, I'm sorry, did you say clean reflective meta-model???

So this:

caller[0] =~ /in `([^']+)'/ ? $1 : '(anonymous)'

vs. the python example:

filename, line, fname, source = traceback.extra ct_stack(limit= 2)[0]
return fname

is what you call clean?? Hmmm ... interesting.

[Ilias Lazaridis]

dr***********@g mail.com wrote:

And I have around one year to wait for Ruby to get rid of the nasty
syntax copied from Perl and make it look as beautiful as Python ....
Then I'll consider switching. ;)

Ummm, I'm sorry, did you say clean reflective meta-model???
yes.
So this:

caller[0] =~ /in `([^']+)'/ ? $1 : '(anonymous)'

vs. the python example:

filename, line, fname, source = traceback.extra ct_stack(limit= 2)[0]
return fname

is what you call clean?? Hmmm ... interesting.

no, It is not.

I've not yet defined what I would call the "clean way".

-

both code examples were provided from the community (limited responses
from python community).

-

Ruby does not pass the evaluation, too (although it is closer, due to
the clean metadata capability).

-

And: Ruby has even lower evolution speed:

http://lazaridis.com/core/eval/ruby.html

..

--
http://lazaridis.com

[Cameron Laird]

In article <11************ **********@g49g 2000cwa.googleg roups.com>,
Nicola Musatti <ni************ @gmail.com> wrote:

[Cameron Laird]

In article <11************ **********@z14g 2000cwz.googleg roups.com>,
<bo****@gmail.c om> wrote:

[Cameron Laird]

In article <11************ *********@g49g2 000cwa.googlegr oups.com>,
Graham Fawcett <gr************ @gmail.com> wrote:

[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
"implemento rs-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 <th****@xs4all. net>

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

[Fredrik Lundh]

Gary Herron wrote:

So how about it... What's your complaint, what's your solution, and why
should we listen?

Nobody will ever know. Check the comp.lang.pytho n/ruby/lisp/etc archives
for more.

</F>