Slashdot Mirror
Guido Goes Google
revividus writes "It seems that Python creator Guido van Rossum has received an offer from Google, and accepted it. Here is also some confirmation."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Google's always been pretty open about heavy Python use. There is fairly interesting presentation by Greg Stein about Python at Goole here (audio only).
[b.belong('us') for b in bases if b.owner() == 'you']
I can't speak for anyone else, but I did make the leap from perl to Python, and have no regrets.
I still use perl for quick-and-dirty text-processing and so forth, but Python is excellent for creating scripts you want to be able to maintain later. The syntax is sparse (compared to most other languages), so there isn't as much code to maintain. I found most of my favorite perl features were also represented (foreach, regular expressions, etc.)
People who've never spent much time with Python will gripe about the whitespace. It was never an issue for me, and I've never had problems with it.
If you plan to do any significant object-oriented programming, Python is very good for that. For procedural programs, the only edge it has over perl is readability, due to the concise syntax.
One thing to keep in mind with Python, however, is that it does NOT convert between numbers and strings automatically, while perl does. It's no big deal to cast a number as a str() or cast a string as int(), but if you don't know about it beforehand, it will get you.
From what I understand, Python is also very nice for metaprogramming, but I've never used it for that. I have used it for quick command-line utilities, GUI apps (with wxPython), and game programming. The object-oriented features are really why I prefer it over perl. They are intuitive, and you have a lot of power over how the objects behave in various circumstances.
If you have any C# experience, I've found you can port C# code to Python with only minor (mostly cosmetic) changes. (This obviously excludes using libraries written for C#, though--I was referring to the syntax of the code itself as being easily ported.)
Sorry if this explanation wasn't technical enough. I was just trying to lay out the general reasons I found a move from perl to Python relatively painless.
Check out my world simulator thingy.
A very interesting project that aims to create a faster Python implementation is PyPy, funded by the EU, by google (with Summer of Code) and by a lot of programmers that donate their own time.
Even the Psyco guys say that the future is in PyPy!
There's a hidden treasure in Python 3.x: __prepare__()
http://en.wikipedia.org/wiki/ALF_programming_langu age
Good point. I think that Python + wxPython + wxGlade is a very powerful combination for clean, fast and maintainable GUI development.
If you do GUIs I suggest to try these tools: they are simple and powerful (wxPython even contains additional classes that are not present in wxWidgets).
There's a hidden treasure in Python 3.x: __prepare__()
Python is self documenting. You should be documenting it as you go along. Everything in python is an object, and every object has a doc string, therefore EVERYTHING in python has documentation built into it. Variables, functions, classes, anything and everything.
Oh, quite true. At Google, we use Python, Java, and C++ for all of our work. Python is critical to our development and infrastructure.
I gave a keynote at PyCon last year about the importance of Python at Google. Some people transcribed the talk. You should be able to find it via Google. (heh!)
In the interpreter, do:
>>> import this
Send email from the afterlife! Write your e-will at Dead Man's Switch.
Ha! Guido would quit in a heartbeat if you tried to make him manage people. That just isn't where he's at. He's absolutely brilliant and loves to write excellent code. Great. We're gonna let him do just that :-)
In any case: yeah, we hired him because we want him to work on Python itself. And as John says later in this thread -- about half his time.
Python has moderately fast bytecode (google stuff could improve a lot here) and it's got a decent oop model and a threading api.
Python's biggest problem from a performance perspective is that the language effectively guarantees operations on several internal objects (e.g. lists, dictionaries, etc) are atomic (from a multithreading point of view). This means that some kind of lock must be held when working with such objects. Because this is how most Python programs spend most of their time, Python usually just has a global lock for all such objects that threads hold whenever they aren't blocked. This means that multithreaded Python apps do not usually benefit from having multiprocessing systems. The obvious alternative (per-object locks acquired when necessary) doesn't seem to help, as it slows single-thread performance significantly.
I think this flaw means that Python cannot really compete with Java or C# on big server systems. And I don't see how to fix it, either, without breaking the beauty of the language.