Python's "only one way to do it" philosophy isn't good?

[Lenard Lindstrom]

Douglas Alan wrote:
> "Terry Reedy" <tjreedy at udel.edu> writes:
> 
>> "Douglas Alan" <doug at alum.mit.edu> wrote in message 
> 
>> | > But why is the ability to abstract syntax good?
> 
>> | It allows the community to develop language features in a modular way
>> | without having to sully the code base for the language itself.
> 
>> Anyone can write modules, experimental or otherwise, without touching the 
>> code base for any particular implementation.
> 
>> For those whose know one of the implementation languages, source code 
>> control systems allow one to do experiments on branches without 'sullying' 
>> the trunk or impeding the development thereof.
> 
> When I said "without having to sully the code base", I meant that one
> can implement a language feature for the target language as a loadable
> module written entirely within the language itself, and without having
> to understand anything particularly deep or specific about the language
> implementation details.
> 
> I.e., I could write a new object system for Lisp faster than I could
> even begin to fathom the internal of CPython.  Not only that, I have
> absolutely no desire to spend my valuable free time writing C code.
> I'd much rather be hacking in Python, thank you very much.
> 

CPython's class system is independent of the interpreter proper. That is 
how two class systems, classic and new-style, can exist in the same 
language. Both class types implement hooks into attribute lookup. By 
providing __getattr__/__getattribute__, __setattr__, and __delattr__ 
methods one can effectively alter object behavior, such as method 
resolution. And metaclasses change the nature of class statements. Novel 
objects systems, such as prototypes, are possible. So the Python 
language provides more of a framework for handling objects rather than 
defining an actual object model. Python is the syntax; objects define 
the behavior.

Finally, with the advent of Python 2.2, built-in types like int and list 
became far more class like. Subclassing became possible. The object 
types were reworking at the interpreter level. No amount of macro 
wizardry could have done it.

>> One of the goals of the PyPy project was to allow people to experiment with 
>> syntax extensions in Python itself.  (But I don't know how easy that is 
>> yet.)
> 
> PyPy sounds like a very interesting project indeed!
> 

PyPy uses aspects without needing macros.

>> But I think that overall the problem of designing new syntax is more
>> in the design than the implementation.  Anything new has to be
>> usable, readable, not clash too much with existing style, not
>> introduce ambiguities, and not move the extended language outside
>> the LL(1) [I believe that is right] subset of CFLs.
> 
> People (myself included) haven't had much trouble implementing nice
> and useful macro packages for Lisp.  Admittedly, it's a harder problem
> for a language that doesn't have a Lisp-like syntax.  I believe that
> Dylan has macros without having a Lisp-like syntax, but Dylan is
> really a dialect of Lisp, only with a more traditional Algol-like
> syntax veneered onto it.  My guess is that a macro developer for Dylan
> would have to be familiar with an underlying hidden intermediate Lisp
> syntax.  (Though I'm just really just spouting that guess out of my
> butt.)
> 

Dylan macros do not use an "underlying hidden intermediate Lisp syntax". 
  They are language-based, doing pattern matching on Dylan language 
elements ( http://www.opendylan.org/books/dpg/db_329.html ).

> A few years back, I designed a somewhat Python-like language with a
> macro facility for a class on dynamic languages and their
> implementations.  I didn't implement it, however, and I doubt that
> I'll have time to get around to it in this lifetime.
> 

It's easy to say Python would benefit from macros. Macros have solved 
problems in Common Lisp and Scheme and so it is assumed they can do the 
same for Python. But no concrete suggestions are made in this thread. No 
specific macro mechanism is put forward for Python. No example is given 
on how to implement some Python feature with it. No point has been 
identified in the Python compiler chain for macro expansion.

When this thread turned to the topic of macros I did an Internet search 
for information on macros relevant to Python. Dylan's macros look 
promising. The Python-inspired language Converge has macros ( 
http://convergepl.org/ ). Michael Hudson's Bytecodehacks package 
supports limited Python macros ( 
http://bytecodehacks.sourceforge.net/bch-docs/bch/module-bytecodehacks.macro.html 
). There is also the __macro__ package, which I still have on my 
computer, but I cannot find its home page.

The __macro__ package simply allows text substitution of source code at 
module import time. The bytecodehack.macro module lets one define what 
amounts to inlined functions. IMO neither package represents a 
productive macro system. And I could find no other attempts to take 
Python macros beyond wishful thinking. So until some solid proposal for 
Python macros is put on the table any discussion of their merits is 
unproductive. I can suggest though that procedural macros are a natural 
starting point given the runtime nature of class and function creation.

--
Lenard Lindstrom
<len-l at telus.net>