Slashdot Mirror
Interviews: Guido van Rossum Answers Your Questions
Last week you had a chance to ask Guido van Rossum, Python's BDFL (Benevolent Dictator For Life), about all things Python and his move to Dropbox. Guido wasted no time answering your questions and you'll find his responses below.
From Google to Dropbox
by nurhussein
Hi, What prompted the move from Google to Dropbox? What did you do at Google, and what are you going to do at Dropbox?
Guido: After seven years at Google I was just ready for some change in environment, and then the Dropbox offer came along. At a high level, my job hasn't changed much: I still
- spend 50% of my time on whatever I want to do for Python in my BDFL role
- am a regular engineer in the organization (not a manager or even TL)
- do a lot of code reviews, architecture and design work
- handle a lot of email
- do a lot of actual coding for my job, in Python
The specifics differ of course. I really did only two things at Google: the first two years I worked on one of the first online code review tools Mondrian, which itself was never open-sourced but begat Rietveld, which did, and is used amongst others, by the Python, Go and Chromium communities. After that I joined Google App Engine where I did a lot of different things, almost all of them in Python. My last big project there was a new Python database API, NDB.
I've been at Dropbox for 7 months and my main project has been the design of the Dropbox Datastore API . It's ironic but not my fault that this also uses the "datastore" moniker -- there's little overlap between Dropbox Datastores and the Google App Engine Datastore.
What's even more ironic is that even though I did much of the design, and wrote two prototypes in Python, the SDKs we released last month only support Java, Objective-C and JavaScript. But I am working on a fix, this interview is just slowing me down. :-)
Why did Python avoid some common "OO" idioms?
by i_ate_god
Interfaces, abstract classes, private members, etc... Why did python avoid all this?
Guido: I can think of two reasons: (a) you don't really need them, and (b) they are hard to do if you have no compile-time type checking. Python started out as a skunkworks project (not endorsed or encouraged by management but not actively prevented), and I wanted results quickly. This led me to remove features that weren't actually needed or urgent; it also led me to do all type checking at run time, which gave me natural constraints on what features Python could support. I also had no religious OO ax to grind -- I just wanted an easy language, and it became OO more or less by accident.
In modern Python there are rough equivalents for all of these, but they don't necessarily work all that well, or they cause a lot of execution overhead, so they are often avoided, but they have their uses and their fans.
functional programming
by ebno-10db
Some people claim that Python is, at least partly, a functional language. You disagree, as do I. Simply having a few map and filter type functions does not make for a functional language. As I understand it those functions were added to the libraries by a homesick Lisper, and that several times you've been tempted to eliminate them. In general it seems you're not a fan of functional programming, at least for Python.
Question: do you feel that the functional programming approach is not very useful in general, or simply that it's not appropriate for Python? It would be nice to hear your reasons either way.
Guido: I'm not a fan of religiously taking some idea to the extreme, and I try to be pragmatic in my design choices (but not *too* pragmatic, see the start of this sentence :-). I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added builtin sum() at the same time we demoted reduce() from a builtin to something in functools (which is a dumping ground for stuff I don't really care about :-).
If I think of functional programming, I mostly think of languages that have incredibly powerful compilers, like Haskell. For such a compiler, the functional paradigm is useful because it opens up a vast array of possible transformations, including parallelization. But Python's compiler has no idea what your code means, and that's useful too. So, mostly I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers).
I also don't think that the current crop of functional languages is ready for mainstream. Admittedly I don't know much about the field besides Haskell, but any language *less* popular than Haskell surely has very little practical value, and I haven't heard of functional languages *more* popular than Haskell. As for Haskell, I think it's a great proving ground for all sorts of ideas about compiler technology, but I think its "purity" will always remain in the way of adoption. Having to come to grips with Monads just isn't worth it for most people.
(A similar comment applies to Scala. It may be the best you can do trying to combine functional and OO paradigms in one language, but the result isn't all that easy to use unless you're really smart.)
Multi-line lambdas
by NeverWorker1
One of the most common complaints about Python is the limitations of its lambdas, namely being one line only without the ability to do assignments. Obviously, Python's whitespace treatment is a major part of that (and, IIRC, I've read comments from you to that effect). I've spent quite a bit of time thinking about possible syntax for a multi-line lambda, and the best I've come up with is trying to shoehorn some unused (or little used) symbol into a C-style curly brace, but that's messy at best. Is there a better way, and do you see this functionality ever being added?
Guido: Really? I almost never hear that complaint except from people who submit questions to Slashdot interviews. :-)
There is indeed a better way, and that is using the 'def' keyword to define a regular function in a local scope. The defined function object becomes a local variable that has exactly the same semantics as a lambda except that it is bound to a local variable, and it doesn't have any of the syntactic constraints. For example, there is *no* semantic difference between
def make_adder(n):
__def adder(x):
____return x + n
__return adder
and this equivalent using lambda:
def make_adder(n):
__return lambda x: x + n
(except that when you introspect the lambda asking for its name, it will say '' instead of 'adder').
Andrew Koenig once pointed out to me that there's one pattern where lambdas are really much more convenient, and that is if you have a long list or dict (perhaps some kind of switching definition) containing lots of lambdas, since if you wanted to do that without lambda you'd end up first having to define lots of little functions, giving them all names, and then referencing them all by name from inside the list or dict. But in that pattern the lambdas are usually simple enough to be lambdas, and if you have a few exceptions, using 'def' before starting the list or dict is a fine compromise.
PyPy
by Btrot69
Do you see PyPy as the future? Or do you remain unconvinced, and -- if so -- why ?
Guido: I'm still unconvinced, for two reasons: (a) they don't support Python 3 (well) yet, and (b) there are lots of extension modules (both third party and in the standard library) that they don't support well. But I hope they'll fix those issues. I think it's competition from projects like PyPy, Jython and IronPython that keeps the CPython project honest and on its toes.
Python in the browser ?
by Btrot69
Over the years, there have been several attempts to create a sandboxed version of python that will safely run in a web browser.Mostly this was because of problems with Javascript. Now that Javascript works -- and we have nice things like CoffeeScript -- is it time to give up on python in the browser ?
Guido: I gave up on it in 1995, so yes. And please don't try to compile Python to JavaScript. The semantics are so different that you end up writing most of a Python runtime in JavaScript, which slows things down too much. (CoffeScript's strength is that it is designed to map cleanly to JavaScript, and the two are now co-evolving to make the mapping even cleaner.)
Python 3
by MetalliQaZ
How do you feel about the current state of the migration to Python 3 (Py3k)? From a user perspective it seems that the conversion of popular libraries has lagged far behind, which has impeded the transition. In my professional capacity, nearly every single system I use lacks an installed 3.x interpreter. In fact, 2.7 is a rarity. I'd like to get your thoughts.
Guido: Curious where you work. I agree that Python 3 migration will still take a long time, but if your systems don't come with Python 2.7 they must be pretty ancient! When I left Google they were about done with the internal transition to Python 2.7 (having successfully migrated from 2.4 to 2.6 over the past few years) and here at Dropbox both the client and the server are using Python 2.7. Both companies are already thinking about Python 3 too.
Back to Python 3 migration, I am actually pretty optimistic. Lots of popular libraries have a working port or are working on one. (The Python Software Foundation also occasionally funds projects to port libraries that are widely used but don't have enough of a community to do a port.) It will take a long time, but I see a lot of progress, and in a few years I expect most new code will be written in Python 3. Totally eradicating Python 2 usage will probably take much longer, but then again, Windows XP isn't quite dead yet either. :-)
Key question for any language designer
by dkleinsc
Have the prospects of Python in any way improved since you grew a beard? To what degree does language success correlate to beard length?
Guido: It is absolutely essential. Just look at Perl's fate -- Larry Wall is just too clean-shaven. :-)
by nurhussein
Hi, What prompted the move from Google to Dropbox? What did you do at Google, and what are you going to do at Dropbox?
Guido: After seven years at Google I was just ready for some change in environment, and then the Dropbox offer came along. At a high level, my job hasn't changed much: I still
- spend 50% of my time on whatever I want to do for Python in my BDFL role
- am a regular engineer in the organization (not a manager or even TL)
- do a lot of code reviews, architecture and design work
- handle a lot of email
- do a lot of actual coding for my job, in Python
The specifics differ of course. I really did only two things at Google: the first two years I worked on one of the first online code review tools Mondrian, which itself was never open-sourced but begat Rietveld, which did, and is used amongst others, by the Python, Go and Chromium communities. After that I joined Google App Engine where I did a lot of different things, almost all of them in Python. My last big project there was a new Python database API, NDB.
I've been at Dropbox for 7 months and my main project has been the design of the Dropbox Datastore API . It's ironic but not my fault that this also uses the "datastore" moniker -- there's little overlap between Dropbox Datastores and the Google App Engine Datastore.
What's even more ironic is that even though I did much of the design, and wrote two prototypes in Python, the SDKs we released last month only support Java, Objective-C and JavaScript. But I am working on a fix, this interview is just slowing me down. :-)
Why did Python avoid some common "OO" idioms?
by i_ate_god
Interfaces, abstract classes, private members, etc... Why did python avoid all this?
Guido: I can think of two reasons: (a) you don't really need them, and (b) they are hard to do if you have no compile-time type checking. Python started out as a skunkworks project (not endorsed or encouraged by management but not actively prevented), and I wanted results quickly. This led me to remove features that weren't actually needed or urgent; it also led me to do all type checking at run time, which gave me natural constraints on what features Python could support. I also had no religious OO ax to grind -- I just wanted an easy language, and it became OO more or less by accident.
In modern Python there are rough equivalents for all of these, but they don't necessarily work all that well, or they cause a lot of execution overhead, so they are often avoided, but they have their uses and their fans.
functional programming
by ebno-10db
Some people claim that Python is, at least partly, a functional language. You disagree, as do I. Simply having a few map and filter type functions does not make for a functional language. As I understand it those functions were added to the libraries by a homesick Lisper, and that several times you've been tempted to eliminate them. In general it seems you're not a fan of functional programming, at least for Python.
Question: do you feel that the functional programming approach is not very useful in general, or simply that it's not appropriate for Python? It would be nice to hear your reasons either way.
Guido: I'm not a fan of religiously taking some idea to the extreme, and I try to be pragmatic in my design choices (but not *too* pragmatic, see the start of this sentence :-). I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added builtin sum() at the same time we demoted reduce() from a builtin to something in functools (which is a dumping ground for stuff I don't really care about :-).
If I think of functional programming, I mostly think of languages that have incredibly powerful compilers, like Haskell. For such a compiler, the functional paradigm is useful because it opens up a vast array of possible transformations, including parallelization. But Python's compiler has no idea what your code means, and that's useful too. So, mostly I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers).
I also don't think that the current crop of functional languages is ready for mainstream. Admittedly I don't know much about the field besides Haskell, but any language *less* popular than Haskell surely has very little practical value, and I haven't heard of functional languages *more* popular than Haskell. As for Haskell, I think it's a great proving ground for all sorts of ideas about compiler technology, but I think its "purity" will always remain in the way of adoption. Having to come to grips with Monads just isn't worth it for most people.
(A similar comment applies to Scala. It may be the best you can do trying to combine functional and OO paradigms in one language, but the result isn't all that easy to use unless you're really smart.)
Multi-line lambdas
by NeverWorker1
One of the most common complaints about Python is the limitations of its lambdas, namely being one line only without the ability to do assignments. Obviously, Python's whitespace treatment is a major part of that (and, IIRC, I've read comments from you to that effect). I've spent quite a bit of time thinking about possible syntax for a multi-line lambda, and the best I've come up with is trying to shoehorn some unused (or little used) symbol into a C-style curly brace, but that's messy at best. Is there a better way, and do you see this functionality ever being added?
Guido: Really? I almost never hear that complaint except from people who submit questions to Slashdot interviews. :-)
There is indeed a better way, and that is using the 'def' keyword to define a regular function in a local scope. The defined function object becomes a local variable that has exactly the same semantics as a lambda except that it is bound to a local variable, and it doesn't have any of the syntactic constraints. For example, there is *no* semantic difference between
def make_adder(n):
__def adder(x):
____return x + n
__return adder
and this equivalent using lambda:
def make_adder(n):
__return lambda x: x + n
(except that when you introspect the lambda asking for its name, it will say '' instead of 'adder').
Andrew Koenig once pointed out to me that there's one pattern where lambdas are really much more convenient, and that is if you have a long list or dict (perhaps some kind of switching definition) containing lots of lambdas, since if you wanted to do that without lambda you'd end up first having to define lots of little functions, giving them all names, and then referencing them all by name from inside the list or dict. But in that pattern the lambdas are usually simple enough to be lambdas, and if you have a few exceptions, using 'def' before starting the list or dict is a fine compromise.
PyPy
by Btrot69
Do you see PyPy as the future? Or do you remain unconvinced, and -- if so -- why ?
Guido: I'm still unconvinced, for two reasons: (a) they don't support Python 3 (well) yet, and (b) there are lots of extension modules (both third party and in the standard library) that they don't support well. But I hope they'll fix those issues. I think it's competition from projects like PyPy, Jython and IronPython that keeps the CPython project honest and on its toes.
Python in the browser ?
by Btrot69
Over the years, there have been several attempts to create a sandboxed version of python that will safely run in a web browser.Mostly this was because of problems with Javascript. Now that Javascript works -- and we have nice things like CoffeeScript -- is it time to give up on python in the browser ?
Guido: I gave up on it in 1995, so yes. And please don't try to compile Python to JavaScript. The semantics are so different that you end up writing most of a Python runtime in JavaScript, which slows things down too much. (CoffeScript's strength is that it is designed to map cleanly to JavaScript, and the two are now co-evolving to make the mapping even cleaner.)
Python 3
by MetalliQaZ
How do you feel about the current state of the migration to Python 3 (Py3k)? From a user perspective it seems that the conversion of popular libraries has lagged far behind, which has impeded the transition. In my professional capacity, nearly every single system I use lacks an installed 3.x interpreter. In fact, 2.7 is a rarity. I'd like to get your thoughts.
Guido: Curious where you work. I agree that Python 3 migration will still take a long time, but if your systems don't come with Python 2.7 they must be pretty ancient! When I left Google they were about done with the internal transition to Python 2.7 (having successfully migrated from 2.4 to 2.6 over the past few years) and here at Dropbox both the client and the server are using Python 2.7. Both companies are already thinking about Python 3 too.
Back to Python 3 migration, I am actually pretty optimistic. Lots of popular libraries have a working port or are working on one. (The Python Software Foundation also occasionally funds projects to port libraries that are widely used but don't have enough of a community to do a port.) It will take a long time, but I see a lot of progress, and in a few years I expect most new code will be written in Python 3. Totally eradicating Python 2 usage will probably take much longer, but then again, Windows XP isn't quite dead yet either. :-)
Key question for any language designer
by dkleinsc
Have the prospects of Python in any way improved since you grew a beard? To what degree does language success correlate to beard length?
Guido: It is absolutely essential. Just look at Perl's fate -- Larry Wall is just too clean-shaven. :-)
There is this language called Lisp. Might have heard of it before.
Erlang, also.
I understand the kiddies are feeling the Clojure love these days as well (although I suppose that just ends up categorized as a Lisp subset)
C'mon Guido, you're smarter than this...
He did answer one question once and for all. The smiley closes the bracket.
https://xkcd.com/541/ All hail the BDFL
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
I know about all the religious arguments pro or against whitespace as syntax. Personally, I am a happy user of python and I actually like the forced indentation, YMMV. But please slashdot, why do you screw up the indentation when the inventor of a whitespace-as-syntax-language gives a code example? This will be too easy for anyone arguing against the use whitespace of syntax.
karma police: arrest this man, he talks in maths; he buzzes like a fridge, he's like a detuned radio. [radiohead]
I asked the Python 3 question and to answer Guido's question of me; I work at a large conglomerate that does a lot of defense contracting. In my area we deal with aerospace applications and so our linux systems are not Internet-facing. They are real-time systems that run simulations and data-acquisition. As you might expect, they only get upgraded when they really need it. We had a PDP-11 down in the lab until 2010.
I'm not sure why I mentioned my workplace other to demonstrate how distant Py3k can seem to be. My main concern was the apparent lack of 3.x support in the big libraries out there. PIL is a great example. Also PyPy. It seems to me that there are many users that will only upgrade when the 3rd party libraries require it.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
borking up the whitespace in a Python code sample? That ain't OK at all.
It may have to do with a sloppy HTML conversion by Slashdot or something, but it is ironic.
P.S. I'm actually a fan of the Python/Haskell whitespace approach.
But sure, just carry on 'dissing functional programming and alienate some more of your core users.
After that post, I seriously doubt you are a core user.....
"First they came for the slanderers and i said nothing."
Did you read what he said? He wasn't dissing functional programming. His point was that FP features require powerful compilers. Python doesn't have that kind of compiler. Therefore the features don't have much use to Python.
By the way, I don't believe they made the print function to be intuitive. They made it because print had no reason to be a statement. Also who said that tuples are more important than arrays? Arrays are really a concept for lower-level languages. Tuples, lists, and dictionaries are higher-level concepts that might be implemented with arrays behind the scenes. Lists function similarly to how many people visualize arrays. The beauty of tuples is that they are immutable, which means that they never change and can be thought of as a single, meaningful package with its contents. In contrast, lists have to be thought of as containers that can contain unknown things that may change at any moment.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"