Guido van Rossum answers questions

Last week ( August 19 - approx. Per. ) You had a chance to ask a question to Guido van Rossum , the Generous Lifelong Python Dictator, regarding any aspects of Python, as well as his move to Dropbox. Guido lost no time in answering some of your questions.

From Google to Dropbox

by nurhussein
Hey. What made you go from Google to Dropbox? What did you do at Google, and what are you doing now at Dropbox?

Guido: After seven years of working at Google, I was ready for any changes in the environment, and here I received an offer from Dropbox. By and large, my work has not changed much. I am still

• I spend 50% of my time on what I usually do according to my role as the Generous Life Dictator
• I am an ordinary engineer in this organization (not a manager and not even lead a group (not Team Leader))
• I often do code inspection, develop architecture and design
• parse a lot of emails
• writing python code

The details of the work certainly differ. In fact, I did two things at Google: At first, I worked on the first online code inspection tool (code review) Mondrian , which, although not open source, spawned Rietveld . Rietveld is now 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 a new Python API for database, NDB .
I have been with Dropbox for 7 months, and my first project was the design of the Dropbox Datastore API . Ironically (I'm not guilty), the word "datastore" is also present here. There are common features in Dropbox Datastore and Google App Engine Datastore.
Another fun item. Despite the fact that most of the design was invented by me, and I wrote two prototypes in Python, the SDK released last month only supports Java, Objective-C, and JavaScript. But I am working on it. Just because of this interview process is not going so fast :)

Why does Python avoid some OOP idioms present in other languages?

from i_ate_god ( this nickname offends the feelings of believers - approx. lane. )
Interfaces, abstract classes, private members, etc ... Why are these things missing from Python?
')
Guido: I see two reasons: (a) you don’t really need them, and (b) they are difficult to implement because there is no type checking at the compilation stage. Python started as a pilot project (not approved or approved by the authorities, but not prohibited), and I wanted to quickly get a working prototype. Therefore, I removed opportunities that were not particularly needed, and which can be postponed; I also had to do all type checks at run time. Hence the natural limitations on the capabilities that Python supports. I was also not a religious fan of the object-oriented approach. I wanted to get a simple language, and object-oriented, he became more likely by coincidence.
In recent versions of Python, approximate analogues of the things you are asking about have appeared. But they do not always work as you expect, or they can lead to unnecessary overhead. Therefore, they are often avoided, but there are also fans of such approaches.

Functional programming

from ebno-10db ( who invented his nickname? - approx. lane. )
Some people claim that Python is at least partially, but a functional language. As far as I can see, you disagree with that. The map and filter functions are not enough for the language to become functional. As far as I know, this function was added to the Lisp language by a developer who yearned for his native home. And you several times broke them to remove. It seems that you are not a fan of the functional paradigm, at least in Python.

Question: Do you think that the 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 make a choice in favor of an 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 the real code. There are situations when map() and filter() very useful, and for other cases there are list expressions (list comprehensions). I hated reduce() because this function was almost always used for two things: (a) to calculate the sum of the elements and (b) to write unreadable code. Therefore, we added the built-in function sum() and transferred reduce() from the built-in functions to the functools module (this is such a dump for all things that I don’t functools :-).
When I think about functional programming languages, I mostly think about languages ​​with an incredibly powerful compiler, such as Haskell. For such compilers, the functional paradigm is very useful, as it provides a huge array of transformation possibilities, including parallelization. But the Python compiler has no idea what your code means. And this is also useful. Therefore, I do not think that there is a point in adding “functional” primitives in Python, because the reasons why these primitives have shown themselves well in functional languages ​​do not fit the Python language. And still the code because of them becomes extremely unreadable for people who are not used to functional languages ​​(and these are the majority among programmers).
And I also think that the modern set of functional languages ​​is not ready for the mainstream. Honestly, I don't know much 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 believe that this is an excellent language for testing all sorts of ideas in compiler technology, but I think that its “cleanliness” will always stand in the way of widespread adoption. The need to deal with Monads will scare many.
(Similar comments apply to Scala. This is probably the best example of combining functional and object-oriented paradigms in one language. But as a result, you have to be really smart to write on it.)

Multi-line lambda

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

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

Guido: Really? People who ask questions on Slashdot almost never mentioned it. :-)
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. With the exception of 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 the equivalent record using lambda:

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

(the only difference is that using introspection, if you ask a question about your name, Lyabda will answer with an empty string '' instead of 'adder' ).
Andrew Koenig once remarked that there is a situation in which lambda is much more convenient than functions. If you have a large list or a dictionary (for example, a certain analogue switch) consisting of a large number of lambdas, then you will need to create many short functions, think up names for them and use them when compiling a list or a dictionary. But in this example, the syntax for single-line lambdas is usually sufficient. As a last resort, you can always use 'def' before creating a list or dictionary.

Pypy

from 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 don't have (good) support for Python 3 yet, 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 the competition with PyPy, Jython and IronPython helps CPython move forward.

Python in the browser?

from btrot69
Over the course of 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 inserting Python into 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. As a result, you will have to implement most of the Python language in JavaScript. That, in turn, will hit on performance. (The power of CoffeeScript is that it was originally designed to be compiled into JavaScript. And now both of these languages ​​are developed in the same way, making the compilation process easier.)

Python 3

by MetalliQaZ
How do you assess the current status of migration to Python 3? From the user's point of view, the transition of the main popular libraries is delayed, which in turn makes it difficult to move to Python 3. In my professional work, I often encounter the lack 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 migration to Python 3 takes a lot of time, but if Python 2.7 is missing on your system, then you are probably stuck in the Stone Age. When I left Google, they almost completed the internal transition to Python 2.7 (the previous migration from 2.4 to 2.6 successfully passed a few 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’m actually a big optimist. Most of the popular libraries already have a working port on Py3k or are porting. (In turn, the Python Software Foundation funds porting 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. To completely get rid of using Python 2 it will take much longer. Again, Windows XP is still alive.

The key question to any language designer

by dkleinsc
How did the perspective of Python change after you grew your beard ? How much success of the language correlates with the length of the beard?

Guido: A beard is absolutely necessary. Look at the fate of Perl - it's all about Larry Wall's perfect shave ( Larry Wall ).

From translator

I enjoyed translating interviews with the Generous Life Dictator. In his answers, there is little water and reflection on abstract topics. He pragmatically looks at Python, appreciates practicality, readability and efficiency. It is a pity that the time has passed when it was possible to ask questions. And then I would ask: "When will JIT compile in Python?" To date, the performance of Python code is inferior to Java, Ruby.