The creator of Python talks about Python

According to the poster, Python creator Guido van Rossum's speech at EuroPython 2015 was divided into a speech and a live Q&A session, but he changed the entire session to a live Q&A session after he took the stage. Before answering questions from the audience, he first promoted the progress of the meeting with a few questions and answers of his own. Topics included Python 3 (and 3.5), why there is no 2.8 version, why there are so many open bugs, Pypy, and what parts of Python he hates.

Django Girls

Van Rossum's own first question was what he thought of Django Girls, the subject of his talk the day before. It was a great conversation, he said, and he loved storytelling. There would be no reference to it in his talk, or any "pretty slides." He was shocked to hear that Ola... or Ola... had drawn squirrels and badgers for the slides.

Another aspect he liked was that they stated that they had no idea what they were doing. It reminded him of when he started writing Python 25 years ago and he had no idea what to do next, for example, he didn't know that a programming language requires a community of different roles.

He was also inspired by the "strong brand" they created in a year, "I expect Ola and Ola and Django Girls will go far."

Python Version

Switching gears, his next question is why developers are switching to Python 3. "Why can't you just give up on Python 3?", he asks himself. He doesn't say people should switch to Python 3, but he doesn't want them to either, but there's a lot of hard work that needs to be done to do something else. For example, the look of these apps and websites, Python 2.7 isn't dead now, and there will be more security fixes, and maybe, in the next five years, there will be a lot more security. Porting to Python 3 will be a lot of hard work, so why bother?

[Guido van Rossum] On the one hand, Python 3 is a "much better language" than Python 2. It's a very teachable language. For example, the Django Girls workshop is entirely developed in Python 3. It's impossible to say that the Django developers didn't do a crappy job with the framework's interfaces. This makes the first development experience with this language (and this framework) much more pleasant.

Python will get better over time. For example, there are "a lot of great new things" in Python 3.5. He said Python 2 is a great language and will remain so, which will gradually bring it closer to the latest version 2.7. The only way to benefit from all the work done by the core developers is to move to Python 3.

A long-standing question is why Python 2.8 was not released, although Van Rossum pointed out that there may be some style obsolescence issues. Python 2.8 does not solve any problems that people want to solve. There are no new features, which means there is no reason to upgrade the version, and the floodgates are open for porting from Python 3. That will require programs to be ported to 2.8 as well as 3.

Unicode was a big hurdle in porting to 3. But "enough is enough". So Python 2 is in a state where it is not getting new features. This allows the core developers to focus on Python 3 and make it better.

He then talked about Python 3.5, which will be completed in September. He was once unable to choose so many features. For example, the performance improvement brought by os.scandir() is very nice, but most users will not notice it. Another part of users will be very happy about the new matrix multiplication operator. Like NumPy and other scientific computing packages will start to use this thing, this feature will be more "natural" than calling a function.

Perhaps his favorite Python 3.5 feature is the syntax hints, which he wrote in the PEP. He put a lot of effort into getting it accepted by the PEP, and he was his own judge, convincing himself to accept his work, which was a little strange. But he still hopes that someone will do an independent code review for him, just like Mark Shannon once did as a BDFL representative, he said.

"If this doesn't come as a surprise to you, the last PEP accepted for Python 3.5 was the async and await keywords he was looking into as interest research. This will provide a more natural way to write code around coroutines."

Public bugs

Recently someone asked him about all the open bugs in the python bug tracker. If you look at any open bug, you will find that the bug may have been patched, there is a long discussion, and even the core developer said that the patch can be merged into the trunk, but the bug is not fixed. Is this an unreliable core developer or a good person? What is the need for these patches?

He said that these problems also exist in some other large projects. Many bugs were not closed in the right way, which led to misunderstanding of documents and accumulation of more bugs. These bugs are difficult to reproduce due to different hardware or development environments. However, there is no patch for this kind of bug.

There are also some feature suggestion bugs with patches attached, but we are generally hesitant to accept these changes because the concerns are not useful, such as not having some features of the same language, or backwards compatibility. It is difficult to accept these patches without breaking all the time.

In addition, the core developers themselves have a lot of work to do, and no one is responsible for merging patches into the Python core code. Therefore, if there is no focus on the core team, the patches and features will generally not be inserted into the merge process.

In a company, these things are a little different. People pay people to do the grunt work, but with open source you have to volunteer to do the unpleasant tasks. Some core developers have been doing the grunt work for too long and want to get out of it. Some open bugs have a long history in the bug tracker for a number of reasons.

Ultimately, there are always a lot of statistical effects that are ignored. If you randomly notice a bug, including closed bugs, you might get a closed bug. Many bugs are closed quickly, and the bugs are simply fixed, similar to that quick fix. But the average lifespan of an open bug grows linearly with the age of the project, he said.

GIL

Some audience members asked about the global interpreter lock (GIL), wanting to know more about this issue and how it was solved. Van Rossum smiled and asked, "How much time do you have?" He briefly described the history of the GIL. After Python was born, multi-core computers appeared. When threads run on different cores, two or more processors update the same object, which creates a competition mechanism, especially in the Python garbage collection mechanism.

A reasonable solution is to lock each object, which protects the data from being corrupted by multiple accesses. But the result is that when there is no lock contention, the locking and unlocking operations are expensive. Some experiments show that the performance of single-threaded programs that do not need to lock will be reduced by 2 times. This means that only programs using three or more threads or cores will benefit from it.

Thus, the GIL was born (although the name didn't come until long after it was added to the interpreter). It's a single lock that effectively locks all objects at once, so that all object accesses are ordered. The problem now is that 10 or 15 years later, multi-core processors are everywhere, and people want to take advantage of them without having to do multiprocessing (e.g., using separate processes instead of threads communicating).

If you were to design a new language today, he said, make it have no mutable objects, or have limited mutability. However, a voice in the audience said, "That's not Python." Van Rossum agreed, saying, "You said what I was going to say." There are a lot of ongoing developer efforts around the GIL, including PyPy Software Transactional Memory (STM), and PyParallel. Other developers are also racking their brains to come up with solutions. If anyone knows a way to remove the GIL and keep the language Pythonic, Van and others would be happy to hear it.

PyPy

He was asked about PyPy, whether he uses it, and whether it will become the default interpreter someday. He doesn't use PyPy, but he downloaded it, played with it for a few minutes, and he liked what he saw. He uses Python in two modes, either writing small scripts to get something done, where he just uses an interpreter that's already installed on his system, or as a Dropbox engineer deploying Python to clusters.

The Dropbox cluster runs a modified Python 2.7, he said, to laughter from the audience. "I told you, it's no secret," he said. Some parts of Dropbox use PyPy because it's faster. But the company is concerned that small incompatibilities will lead to bugs that won't be easy to track down. "We've had enough of that."

PyPy proved that you could run Python faster than CPython. It also provided a testbed on which to test interesting ideas like STM. But the conservative principle is to use PyPy only when you need to speed it up. The problem with this is that by the time you find out, you have already deployed it on so many machines that it is difficult to migrate. Therefore, this is very similar to the problem of migrating to Python 3.

Dropbox has a lot of dependencies on third parties, some of which cannot even be refactored on its source code. The same is true for companies that use tens of thousands of lines of Python code in production environments, and he found that Google was also like this, and it was difficult to migrate.

All in all, PyPy is a "very cool project." But it has a lot of boxes that need to be easier to check. He half-jokingly suggested that perhaps PyPy needs to rent Ola and Ola from DjangoGirls to create a larger project community.

Favorite

[Guido van Rossum]

The next 5 questions were about things he likes. Favorite web framework? He said he only writes one web app in any one framework, and the first one he tried was Flask. Favorite testing library? He mainly uses unittest and mock from the standard library. Editor? He uses Emacs now, but originally used vi (both to varying degrees of acclaim). He still occasionally uses vi (or Vim), but after using it for 5 minutes, he'll spend 15 minutes getting used to Emacs again.

What is your favorite language besides Python? He used to say C, but it's "kind of boring." People he trusts tell him modern C++ is a great language. He likes Go, but hasn't written anything meaningful in it. When he talked to the designers, he liked the look of Swift, which stole a lot of stuff from Python. It's easy to copy the bad things you like from a language and end up with a bunch of illogical features, but the designers of Swift don't seem to have done that. ***, favorite anomaly? He smiled softly amid more cheering and laughter and answered keyboard interrupts.

What he hates

The first question was what he hated about Python. He immediately answered, "Everything to do with packaging and distribution." There were always issues with version crossovers and dependencies that caused "never-ending confusion." He dreaded when a colleague would come up to him and ask him "a simple Python question," and half of it would be some kind of input path problem with no easy solution.

Then, his time was up. EuroPython organizers gave each keynote speaker a gift: a Basque beret and a large handkerchief. They appeared at the end of Van Rossum's talk.