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).
It would be great to see Python get some better documentation tools
Doxygen claims to support Python.
XML is a known as a key material required to create SMD: Software of Mass Destruction
He's supposed to be spending 50% of his time on Python itself, which is a lot more than he was able to spend on it in his last job.
In L&S's "Anatomy of a search engine article" they wrote:
In order to scale to hundreds of millions of web pages, Google has a fast distributed crawling system. A single URLserver serves lists of URLs to a number of crawlers (we typically ran about 3). Both the URLserver and the crawlers are implemented in Python
http://www-db.stanford.edu/~backrub/google.html
A way of returning a favor, perhaps?
[b.belong('us') for b in bases if b.owner() == 'you']
It would be great to see Python get some better documentation tools as well so that it'd be easy to generate documentation on par with the Java and .NET documentation.
I've always found help(object in question) in the interpreter to be more efficient than looking it up in the sun javadocs or on msdn.
And of course if Google wanted to really screw with both Sun and Microsoft, especially Microsoft, they could create their own cross-platform web and gui toolkits
WxWidgets?
PyGTK?
absolutely.
Often times it's only required to rewrite the most crucial bits of an app. This is fairly straightforward in Python.
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__()
For the curious......
The Zen of Python (by Tim Peters)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
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.
Danny Thorpe was also recently hired (Borland Chief Scientist, Delpi/Kylix compiler architect).
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.
`... Python get some better
documentation tools as well so that
it'd be easy to generate documentation
on par with the Java and
documentation.
I make this same mistake everytime I program in python. If you dont read the docs [1] & other peoples code you can write functional code, but with a third to a half bloat penalty. That is of course unless you read lots of example code or the docs...
So check again. Because PyDoc [2] is a tool that displays the documentation, from the source. It is pretty much on par with Java and
Reference
[1] google on `PyDoc the module`, `look for Ka-Ping Yee and PyDoc`:
http://www.google.com/search?q=pydoc
[Accessed Friday, 23 December 2005]
[2] PyDoc, `The python documentation module by Ka-Ping Yee and PyDoc`:
http://del.icio.us/goon/pydoc
[Accessed Friday, 23 December 2005]
peterrenshaw ~ Another Scrappy Startup
wxPython is terrible!!! it has loads of widgets which is great, but its like programming c++ in python. it is not pythonic at all! its a terrible wrap. if it was better wrapped and more pythonic it was def be the best GUI framework for python, but as it stand i say it is really terrible.