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. :-)
Or maybe someone should consider such silliness when they make a new language.
Well, leaving aside the fact that neither of them will compile because of lack of whitespace. Editors, you might want to think about when use of the <pre> tag is appropriate.
I still wish the parrot project took off and combined with Perl. Just imagine the poor joy using Lambda's combined with Perl and white spaces? Sounds like a pure paradise.
http://saveie6.com/
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.
"Guido wasted not time answering your questions and you'll find his responses below."
Just like editor wasted not time editing/checking the summary before posting.
Zep--
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]
What makes the one line lambda worse is the fact that in Python, not everything is an expression.
That one change would clean up so much bullshit in the language.
Other than the redundant self's everywhere because he was stupid enough to not include lexical scoping early on.
It is a dumb OO language, at least as dumb as C++
What is not appropriate is for a language to rely on whitespace.
factor 966971: 966971
It is absolutely essential. Just look at Perl's fate -- Larry Wall is just too clean-shaven. :-)
What fate? Having multi-line anonymous functions? Being stable? Still being popular? Another language growing in popularity does not threaten that.
No, you knob: it's a Monty Python reference, like the language itself.
Which is why python is dead to me.
I only tolerate makefiles because I must.
Although on the whole I think using whitespace to define blocks works very well, and I use python quite a lot, I think optional braces would be extremely useful at times. i.e. for copying and pasting code fragments. Python code is absolute pain in the butt to copy and paste to/from browsers, repl, etc.
But braces are clearly against Guido's religion.
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"
Can you do one there?
I think "Benevolent Dictator For Life" is based on his love for the BBC show "Monty Python's Fying circus". Rossum named "python" after that.
I personally, don't recall any skit about a "Benevolent Dictator For Life". Does any one else?
Haskell and monads are hard, so functional programming is hard, huh?
Rubbish.
OOP is just as full of esoteric, mind-bending weirdness as functional programming is, and for a language that prides itself on readability python sure has it's share of WTF magic. If you think reduce is hard to understand, you might like to try explaining reduce versus some of the following python features to a noob:-
OOP is a great way to write crappy, bloated, buggy, unmaintainable code, and ruby does it better than python. As you admit yourself python will never be the language of the web either. But sure, just carry on 'dissing functional programming and alienate some more of your core users.
It must be painful to be as intelligent as you believe you obviously are and yet unable to develop your own programming language
Someone should consider what a posting to slashdot would look like when they make a new language...?
Luckily, both of your opinions on whitespace were not, and are not, either significant or involved in Python's design.
And that's why you two don't have to be dead to me. :)
Plus, you can keep working with whatever it is that you DO like. Imagine that!
I've fallen off your lawn, and I can't get up.
Yeah, I was going for funny but I guess no one got that.
I dislike whitespace having meaning, but was just trying to make a joke. As you noticed the idea was ridiculous, thus the joke.
Interesting interview. Surely there were more important topics but if nothing else this interview was useful in that it taught me it's okay to use the parenthesis at the end of a smiley to serve double duty as the end of a parenthetical statement (kind of like this one :-). At least when your smiley is left in plain text, that is.
What makes the one line lambda worse is the fact that in Python, not everything is an expression. That one change would clean up so much bullshit in the language.
Or perhaps it makes the one-line lambda better...? As per Guido's own example, lambda's are essentially redundant, as you can achieve the same results with a locally-defined function. The one real difference is that certain things aren't permitted in a lambda, because they're not expressions... which makes a lambda an approximation of a true function, rather than a procedure (Python's "functions" are in reality "procedures")....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
I've written an AVL tree implementation for Python, but I really think an ordered map ought to be a standard facility. It's standard in Java and C++, but sorely missed in C and Python.
yeah, the more you use it and think about it, the uglier it gets
The same result with nastier, more verbose syntax.
Fuck that shit. When I want nasty, verbose syntax I just go straight to Java or C++
Lua is better than Python in every way.
Unable or unwilling?
Two different things.
The programming world would have been better off if both Guido and Rasmus stayed away and got a job flipping burgers.
So no, you can't create a whole program functionally, but if FP was incorporated effectively into multi-paradigm development, it would make simpler debugging no end. What do I mean by properly? FP should be a limited subsystem. No side-effects: no printing, no information, no condition changes or varying claims. This has to be an strong concept (with the possible exemption of debug info). Techniques can contact features, and features can contact other features, but features can't contact procedures. This has to be an strong concept, and I don't beleive most multi-paradigm 'languages' implement it. Why does it have to be unbreakable? Because the whole factor is to decrease debugging attempt. With real FP, bug monitoring is (relatively) easy: if the operate gives the incorrect response, there's a bug in it; if it gives the right response, there's no bug. But as soon as you allow condition changes and other adverse reactions, it's a process, not a operate, and a side-effect bug might only display itself further down the range (eg you unintentionally keep an A in the create shield and the next concept gets an invalid A at the start) and you're remaining on a looooong search. It's regrettable that program control in Python is such a blunder, mostly for traditional reasons. There's quite a bit of good items on PyPI these days, and if we were beginning over, I think we'd do better to restrict the conventional collection to a small set of important fundamentals, and to advertise the best collections from outside resources via the conventional program database and resources. I do a reasonable bit of development in Python and curly-bracket 'languages' (C, C++, JavaScript, PHP, etc.) and remarkably, a forgotten/misplaced wavy segment in any of those various curly-bracket 'languages' seem to crack my rule greatly more often than indent problems do. | Cheap Umrah Packages | Cheap flights To Harare
Ruby has private members as is far more dynamic than Python is.
At least the idiot admitted the OO system was an hacked-on after-thought.