[Python-3000] pep 3124 plans (original) (raw)

Talin talin at acm.org
Sat Jul 21 20:04:55 CEST 2007

Joe Smith wrote:

The effects of this can be wonderful. A package could convert some of a frameworks functions to generics, to allow them to handle the new objects the package provides. It might also need to add some before and after methods to ensure that the user of the module, it looks like the framework was designed to support the module in question, when in fact, it was not. The idea being the package can basically make the needed changes so that everything just works. All without having to duplicate any code from the framework itself. See the benefits? (The framework mentioned could be a major framework like ZOPE, just an average package, or even a simple module.)

When considering the decision to include a new feature into the language, one has to consider the costs as well as the benefits. You've made an impassioned argument showing all the wonderful power and expressiveness of these various features. However, power and expressiveness are not the only factors that should be considered.

To give an analogy, think back 20-25 years ago, when there was still a vocal contingent of programmers who were in favor of self-modifying assembly code. Expert hackers would show the amazing power of this technique, all of the wonderfully clever tricks that you could accomplish.

(I remember this because I was writing games back them, and self-modifying code was the only way you could write 6502 assembly code that was actually efficient. Since the 6502 had no 16-bit index registers, the only way to have efficient arrays larger than 256 bytes was to calculate the address and then modify the 16-bit address field of the subsequent instruction.)

At the same time, however, this clever technique came at a cost: Programs that were very difficult to debug or even understand. Many people spoke out against it, and for a time it seemed that the technique was a dying art.

Today we have the best of both worlds: We still have self-modifying code, but nowadays we call it JIT: Just-In-Time compilation. Instead of a free-for-all where a programmer can modify any arbitrary memory address, instead the power of run-time code generation is safely sandboxed inside of a JIT compiler component that is very competent at hiding the grisly details from the programmer.

Now, don't think that I am directly comparing method combination to self-modifying assembly code. I'm not saying that such things are inherently dangerous and should be avoided.

Rather, what I am trying to point out is the thought process that should be applied to any new feature.

Python is a "small" language in the sense that it's easy to hold the entire syntax in your head, and lots of people want to keep it that way. This does not mean that we can't move forward with new features. But it means that each feature needs to be judged and weighed as to how much it affects that "mental smallness" of the language.

Generic functions are favored because they have the potential to shrink certain kinds of problems. I don't mean in the sense of requiring the programmer to type less keystrokes, but in the sense of shrinking how much brainpower it takes to think about the problem.

But even then it took Guido several months (according to a posting he made some time ago) of thinking about generics before he reached his "Aha" moment with regards to completely grokking the concept. This focus on practicality rather than rocket science is exactly why Guido's a good gatekeeper in these matters - if he doesn't understand it why it's important or useful, it probably means that lots of other Python developers won't either.

-- Talin

More information about the Python-3000 mailing list