python and macros (again) [Was: python3: 'where' keyword]

michele.simionato at gmail.com michele.simionato at gmail.com
Wed Jan 12 06:56:19 CET 2005


Paul Rubin:
> michele.simion... at gmail.com writes:

>> <about Scheme macros>

> It wasn't obvious how to do it in Scheme either. There was quite
> a bit of head scratching and experimental implementation before
> there was consensus.

Actually I am not convinced there is consensus yet, i.e. there is a
non-negligible minority of schemers convinced that original Lisp
macros where better, not to talk of common lispers ;)

>> 3. We would add to Python the learning curve of macros and their
>> subtilities and we do not want it.

> I can't imagine how it could be worse than the learning curve of
> __metaclass__, which we already have.

To me, learning macros *and their subtilities* was much more difficult
than learning metaclasses.

>> 4. Macros would complicate a lot Python module system.

> I don't see how, but maybe I'm missing something.

Go to comp.lang.scheme and google for "macros and module system";
you will get everything you want to know and much more!

>> 5. We have Guido providing a good syntax for us all, why we should
be
>> fiddling with it? More seriously, if some verbosity is recognized
>> in the language (think to the "raison d'etre" of decorators, for
>> instance) I very much prefer to wait for Guido to take care of
>> that, once and for all, than having 100 different custom made
>> solutions based on macros.

> Every time some newbie asks an innocent "how do I ..." question, we
> see unbelievably horrid answers from gurus. Just check the FAQ about
> conditional expressions, etc. I just don't see Python syntax changes
> as forthcoming.

Well, I see this as a positive fact. If a syntax is contrived (such as
a ternary
operator, for instance) it is better *not* to have it than to have one
hundred custom
made syntaxes. At the end, we are just talking about syntax sugar here,
not about
lack of functionality.

>> What I would be interested in is a Lisp/Scheme implementation
>> compiling to Python bytecode, but I am not aware of any project
>> in that direction.

> But that sounds like a bizarre idea. Python bytecode is just a
> CPython artifact, not part of the language. And it's not even that
> good an artifact. Good Lisp/Scheme implementations compile to native
> code that beats the pants off of CPython bytecode. It would make much
> more sense to have a Python implementation that compiles Python to
> S-expressions and then lets a high performance Lisp or Scheme system
> take care of the rest.

This is a bizarre idea if you want to make Python run faster. It is not
so bizarre
if what you want is to have access to Python from Lisp/Scheme in the
same sense 
Jython has access to Java.


         Michele Simionato




More information about the Python-list mailing list