Guido van Rossum: Building an Open Source Project and Community

A long (close to two hours) audio presentation about Python's history and philosophy.

LtU readers will find a lot to disagree with (especially in part 2), for instance when Guido discusses dynamic languages and typing. And yet, I think Guido tries to be reasonable, even though I disagree with some of his conclusions.

Be that as it may, this talk provides a useful summary of Python's history, and some idea about the workings of the Python community. Long time readers will remember that I think language communities play an important, yet under appreciated, role in language evolution and success.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Python is pretty trendy langu

Python is pretty trendy language these days, but we Ltu readers know better - it's just a Lisp in infix clothes :-) Though, I personally like Python community, it's quite active and clever.
From PL point of view, Python seems more interesting to me than confused and buzzword driven "OO+XML+JAVA+dotnet+design pattern+UML" commercial bunch, reinventing Lisp wheel in laughable square bracket syntax ways.


"it's just a Lisp in infix clothes"

and without proper tail-recursion, macros and a definite taste for imperative loops.

but yes, a sweet language with good libs. not unlike ruby btw.

It's just a...

All languages are just Lisp in infix clothes... except for Ruby, which is a procedurally camoflaged Smalltalk (which is a Lisp in message-passing clothes). Oh yeah, some of them have type checkers thrown in, too :-).

On Python

Good thing Guido didn't decide to write about topics such as:

  • Understanding map, filter and reduce
  • How to implement a fast interpreter
  • How to implement real garbage collection without refcounting

How to implement a fast inter

How to implement a fast interpreter

Implementing a fast interpreter or compiler for Python is not at all trivial. I realize your experience is limited to writing glorified Forth interpreters, so this might come as a shock to you.

How to implement real garbage collection without refcounting

CPython has had a mark-and-sweep GC for a long time now. Reference counting is still used but there is nothing "un-real" about it since the GC takes care of collecting cycles.

Language and implementation aren't entirely independent...

Implementing a fast interpreter or compiler for Python is not at all trivial.

I think that was part of the point. The language design of Python is such that it becomes very difficult to make it speedy. The Psyco guys did a very admirable job, they had to jump through hoops to do it.

Granted, Python didn't have speed as a design goal in the first place. And for the vast majority of programs, that seems to be perfectly fine.

The "fast enough" argument is a fallacy.

All other things being equal, the more perfomant solution is preferrable. Thus, you really need to spend some time proving in an objective manner that the cuts in performance are justified. (In my opinion, they are not.)

How would you prove such a thing?

Especially divorced from a specific context? And why is the burden of proof on the other party; whereas you offer only your opinion?

Whether or not something is "fast enough" is generally an engineering/design question, not a scientific question. One cannot claim that Python is, or is not, "fast enough", or that the performance issues with it is "justified" or not, without considering what it's being used for.

Is Python fast enough to implement the Quake graphics engine on a mid-range PC with a bare-bones graphics chip? No, it's probably not. Given a suitably souped-up futuristic machine, OTOH, maybe.

Is Python fast enough to implement glue code between a HTTP server (ie apache) and an RDBMS (ie MySql) running on stock server hardware? Much practical experience says yes, it is. OTOH, were you to replace the stock 2005 server hardware with a PC of ten years vintage; the whole system would suck--the overhead of Python probably would no longer be acceptable given those constraints.

Neither observation is Not "proof"; but the question you pose isn't testable/proveable without extensive qualification.

Guess where Python is routinely deployed?

Similar analyses should apply to other aspects of software quality; namely correctness, security, reliability, robustness, fitness-for-purpose, extensibility, scalability, expressiveness, and such. Is proof by formal method an appropriate design technique for a mission-critical app like a heart monitor? Certainly. For a crud screen? 'Twould be a waste of time and money.

I guess what I'm talking about... keeping a certain "conceptual barrier" between the abstract computational model and technical implementation details of compiler writing.

There should be no reason why compiler internals should influence our language spec.


There should be no reason why compiler internals should influence our language spec.

Yeah, well, but there are reasons.

Absolutist positions

That's an absolutist position; much like "there should be no reason why a database should ever be denormalized", or "there should be no reason why a type test should occur at runtime", or "there should be no reason why a visible side effect should be allowed".

While all four (counting yours) are good statements of principle (though all of them are likely to be the subject of debate), it is exceedingly difficult to construct practical, useful, useable, non-trivial systems which follow all (or any) of those rules religiously. I'm sure it's been done, but it's difficult.

Point taken.

For the record, I support all three of the other statements you made. :)


All other things being equal...

yes, thankfully, a C++ solution most definetely is not the same as a Python one, so merely choosing the "performant" solution is not always a good deal...


I'm a dogmatic Python coder, too. :)

Refcounting is a feature

"How to implement real garbage collection without refcounting"

Python's refcounting is a feature. Destructors are actually useful in Python, and I appreciate not being required to manually close files.

Anyway, the semantics of Python may be lacking in some ways, but it has a good mix of useful features that work well together, and that's what's desired for a language of its kind.

GC / ref counting

You noticed, I hope, that this issue is discussed at length by Guido in the talk.

A good paper to read about finalization vs. destructors is this one.

Sorry, I had listened to the

Sorry, I had listened to the talk earlier, but I didn't remember that he covered reference counting. I skimmed it again, but the only part I could find on reference counting was about 7 minutes into the second part, and he didn't mention destructors or finalizers there, so I'm not sure if I understand what you're saying. Do you mean that I used the term "destructor" incorrectly?

I wasn't clear

Do you mean that I used the term "destructor" incorrectly?

No. I simply wnated to let others know that Guido talks about "real" gc versus ref-counting. It's one of the explanations he gives as to why Java produces more out of memory errors..


Thanks for the clarification and the interesting link.