Guido van Rossum answers questions

Original author: samzenpus
  • Transfer
Last week ( August 19th - approx. Per. ) You had a chance to ask a question to Guido van Rossum , the Generous Lifetime Dictator of Python, regarding any aspects of Python, as well as his move to Dropbox. Guido without losing time answered some of your questions.

From Google to Dropbox


by nurhussein
Hello. What made you move from Google to Dropbox? What did you do on Google and what are you doing now on Dropbox?

Guido: After seven years at Google, I was ready for any changes in the environment, and there was an offer from Dropbox. By and large, my work has not changed much. I am still
  • I spend 50% of the time on what I usually do according to my role as the Generous Life Dictator
  • I'm an ordinary engineer in this organization (not a manager and I don’t even manage a group (not Team Leader))
  • I often do code inspection, develop architecture and design
  • make out a lot of emails
  • I am writing Python code

Work details are of course different. In fact, Google, I did two things: the first two years I was working on the first online code inspection tool (below code review) the Mondrian , which though was not open source, but spawned Rietveld . Rietveld is currently used in Pyhon, Go, and Chromium projects. After that, I joined the Google App Engine, where I did a lot of different things, mostly related to Python. My last big project was the new Python API for the database, NDB .
I have been working at Dropbox for 7 months, and my first project was the Dropbox Datastore API design . Ironically (it's not my fault), the word “datastore” is also present here. Dropbox Datastore and Google App Engine Datastore have similarities.
Another fun part. Despite the fact that most of the design was invented by me, and I wrote two prototypes in Python, the SDKs released last month only support Java, Objective-C and JavaScript. But I am working on it. Just because of this interview, the process is not going so fast :)

Why is Python avoiding some OOP idioms present in other languages?


from i_ate_god ( this nickname offends the feelings of believers - approx. per. )
Interfaces, abstract classes, private members, etc. ... Why are these things missing in Python?

Guido:I see two reasons: (a) you really do not need them, and (b) they are difficult to implement, since there is no type checking at the compilation stage. Python started as an experimental project (not approved or approved by the authorities, but not forbidden), and I wanted to quickly get a working prototype. Therefore, I removed the features that were not particularly needed, and which can be postponed; I also had to do all type checks at run time. This gives rise to natural limitations on the features that Python supports. I was also not a religious fan of the object-oriented approach. I wanted to get a simple language, but it became more object oriented rather by coincidence.
In recent versions of Python, approximate analogues of the things you are asking for have appeared. But they do not always work as you expect, or they can lead to unnecessary overhead. Therefore, they often try to avoid them, but there are also fans of such approaches.

Functional programming


from ebno-10db ( who invented a nickname for him? - approx. per. )
Some people say that Python is at least partially, but a functional language. As far as I can see, you do not agree with this. Functions mapand filterit is not enough to become a functional language. As far as I know, these functions were added to the Lisp language by a developer who is homesick. And you tried several times to remove them. It seems like you're not a fan of the functional paradigm, at least in Python.

Question: Does it seem to you that a functional approach to programming is not very useful in principle, or that it does not fit Python? In any case, I would like to hear your opinion.

Guido:I do not like to choose one or another idea based on religious preferences, and I try to be pragmatic in choosing a design (but not very pragmatic, see the beginning of the sentence :-). I appreciate the readability and usefulness of real code. There are situations when map()they are filter()very useful, and for other cases there are list expressions (list comprehensions). I hated reduce()it because this function was almost always used for two things: (a) to calculate the sum of the elements and (b) to write an unreadable code. Therefore, we added a built-in function sum()and transferred it reduce()from the built-in functions to the module functools(this is such a dump for all kinds of unnecessary things for me :-).
When I think about functional programming languages, I mainly think about languages ​​with an incredibly powerful compiler like Haskell. For such compilers, the functional paradigm is very useful, as it provides a huge array of transformation capabilities, including parallelization. But the Python compiler has no idea what your code means. And this is also useful. Therefore, I do not think that it makes sense to add “functional” primitives in Python, because the reasons why these primitives have shown themselves well in functional languages ​​are not suitable for the Python language. And because of them, the code becomes extremely unreadable for people who are not used to functional languages ​​(and most of them are among programmers).
And I also think that the modern set of functional languages ​​is not ready for the mainstream. Honestly, I know little of functional languages ​​other than Haskell. But any language less popular than Haskell is probably less applicable in practice. And I have not heard of languages ​​more popular than Haskell. As for Haskell, I think this is a great language for testing all kinds of ideas in compiler technology, but I think that its “purity” will always stand in the way of widespread adoption. The need to deal with Monads will scare away many.
(Similar comments relate to Scala. This is probably the best example of combining functional and object-oriented paradigms in one language. But as a result, you need to be really smart to write in it.)

Multi-line lambdas


from NeverWorker1 ( another example of strange nicknames - approx. per. )

One of the most frequently heard complaints about Python is the restriction on the use of lambdas. Namely, the restriction in one line and the inability to make assignments. Obviously, the reason for this is the important role of spaces in Python (if I understood your comment on this correctly). I thought a lot of time about the possible syntax of multi-line lambdas, and the best thing that came to my mind was to try to shove some unused (or rarely used) characters inside curly braces in the style of the C language. But in the best case this will lead to confusion in the code. Can it be more convenient, and will multi-line lambdas ever be added?

Guido:True? People who ask questions on Slashdot almost never mentioned this. :-)
You can make it more convenient - use the 'def' keyword to define a regular function in the local area. The resulting function will be stored in a local variable and will have exactly the same semantics as lambda. Except for binding to a local variable. I do not see any syntactic restrictions. For example, there is no semantic difference between

def make_adder(n):
  def adder(x):
    return x + n
  return adder


and an equivalent notation using lambdas:

def make_adder(n):
  return lambda x: x + n


(the only difference is that using introspection, the Lyabda will answer with a blank line '', instead of 'adder').
Andrew Koenig once noticed that there is a situation in which lambdas are much more convenient than functions. If you have a large list or dictionary (for example, a certain analogue of switch) consisting of a large number of lambdas, then you will need to create many short functions, come up with names for them and use them in the preparation of the list or dictionary. But in this example, the syntax of single-line lambdas is usually enough. As a last resort, you can always use 'def'before creating a list or dictionary.

Pypy


by Btrot69
What do you think the future is for PyPy? Or are you still in doubt, and why?

Guido: I still doubt for two reasons: (a) they do not yet have (good) support for Python 3, and (b) there are many modules (in the standard library and third-party) that are poorly supported in PyPy. But I hope they fix these problems. I believe that competition with PyPy, Jython and IronPython helps CPython move forward.

Python in browser?


by Btrot69
For several years, various attempts have been made to create Python in a sandbox that can be safely run inside a web browser. Mostly this way, people tried to fix JavaScript problems. Now that JavaScript is working - and there are cool things like CoffeeScript - can you stop embedding Python in your browser?

Guido:I stopped doing this in 1995. That is, the answer is yes. And please do not try to compile Python in JavaScript. These languages ​​have very different semantics. In the end, you will have to implement most of the Python language in JavaScript. Which, in turn, will hit performance. (The strength of CoffeeScript is that it was originally designed to be compiled into JavaScript. Now both of these languages ​​are developing in the same way, making the compilation process easier.)

Python 3


from MetalliQaZ
How do you assess the current state of migration with Python 3? From the user's point of view, the transition of the main popular libraries is very delayed, which in turn makes it difficult to move to Python 3. In my professional activity, I often encounter the absence of Python 3.x on almost all systems. Even version 2.7 is still rare. It is interesting to hear your opinion.

Guido:I wonder where you work. I agree that migrating to Python 3 is time consuming, but if Python 2.7 is missing from your system, then you are probably stuck in the Stone Age. When I left Google, they almost finished the internal migration to Python 2.7 (the previous migration from 2.4 to 2.6 successfully went several years ago). Here in Dropbox, both the client and server use Python 2.7. Both companies are already thinking about Python 3.
Returning to migration to Python 3, I am actually a big optimist. Most popular libraries already have a working port on Py3k or are involved in porting. (The Python Software Foundation, in turn, finances the porting of projects that are widely used, but do not have a community sufficient to prepare the port). It will take a lot of time, but I see the light at the end of the tunnel. I think in a few years most of the new code will be in Python 3. It will take much more time to completely get rid of using Python 2. Again, Windows XP is still alive.

The key question for any language designer


by dkleinsc
How did Python's prospects change after you grow a beard ? How much does tongue success correlate with beard length?

Guido: A beard is absolutely necessary. Look at the fate of Perl - the whole thing in a perfect shaving Larry Wall ( of Larry the Wall ).

From translator


I enjoyed translating the interview with the Generous Lifetime Dictator. There is little water and thought on abstract topics in his answers. He pragmatically looks at Python, appreciates practicality, readability and efficiency. It is a pity that the time has passed when you could ask questions. And then I would ask: “When will the JIT compilation in Python appear?” Today, the performance of Python code is inferior to Java, Ruby.

Also popular now: