[plt-scheme] An Editors Tale

On Jan 29, 2004, at 4:27 PM, Ken Anderson wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> I was hoping that with only ~100 methods (maybe fewer are the real 
> issue) it might be possible to rewrite the classes to avoid these meta 
> hacks.
> Maybe the Scheme astronomers can classify the black holes into a few 
> types that can be delt with somehow to make analysis possible.  Of 
> course, this might be harder than it looks .  I just didn't want you 
> guys to give up on Python, until, well now.  It would be cool if 
> Scheme guys could make Python a better language.

Jeremy and I had a brief discussion on this at LL3. I believe that the 
features I dislike are hard-wired into Python and are acclaimed to be 
major components. So I doubt that the Python community is interested in 
listening to people like us.

For another example of how much Pythonistas love this stuff, see

   http://www.linuxjournal.com/article.php?sid=3882

A relevant quote:


"I had already designed and written the three object classes (that's 
what took four days, most of it spent getting the layout of the widgets 
just right). Each had a method that caused it to pop up a GUI edit 
panel to modify its instance data. My last remaining problem was 
somehow to transform the dead data in this Python initializer into live 
objects.

I considered writing code that would explicitly know about the 
structure of all three classes and use that knowledge to grovel through 
the initializer creating matching objects, but rejected that idea 
because new class members were likely to be added over time as the 
configuration language grew new features. If I wrote the 
object-creation code in the obvious way, it would be fragile and tend 
to fall out of sync when either the class definitions or the 
initializer structure changed.

What I really wanted was code that would analyze the shape and members 
of the initializer, query the class definitions themselves about their 
members, and then adjust itself to impedance-match the two sets.

This kind of thing is called metaclass hacking and is generally 
considered fearsomely esoteric--deep black magic. Most object-oriented 
languages don't support it at all; in those that do (Perl being one), 
it tends to be a complicated and fragile undertaking. I had been 
impressed by Python's low coefficient of friction so far, but here was 
a real test. How hard would I have to wrestle with the language to get 
it to do this? I knew from previous experience that the bout was likely 
to be painful, even assuming I won, but I dived into the book and read 
up on Python's metaclass facilities. The resulting function is shown in 
Listing 3, and the code that calls it is in Listing 4.

Listing 3

Listing 4

That doesn't look too bad for deep black magic, does it? Thirty-two 
lines, counting comments."
Eric Raymond

-- Matthias