[Python-3000] pep 3124 plans

[Talin]

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