Paul Rubin wrote:
Well the necessity to understand metaclasses could in some ways be regarded as the push for the summit, and therefore isn't something that would trouble newbies. Given that we are having this discussion in the context of a posited "where" clause intended to allow "multi-statement expressions" (whatever they turn out to be) I would still argue you are discussing the totally unnecessary.[EMAIL PROTECTED] writes:
2. One could proposed hygienic pattern-matching macros in Python, similar to Scheme syntax-rules macros. Again, it is not obvious how to implement pattern-matching in Python in a non-butt-ugly way. Plus, I feel hygienic macros quite limited and not worth the effort.
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.
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. If it was done in a way that most of us would just rely on a few standard ones, that would be fine.
Given that Guido is on record as saying that expressions aren't statements because he wants those things to be separate, I don't really see why there's this consistent pressure to reverse that decision.
There's a reason for this ...
4. Macros would complicate a lot Python module system.
I don't see how, but maybe I'm missing something.
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.
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.
Which would be a worthier goal than trying to graft macros on to Python. You responded that macros would be difficult to implement in m4 because (in essence) of the indented structure of Python. I'm not convinced they'd be any easier in Python, and I'm *certainly* not convinced that their addition would improve Python's readability.
At best it would offer new paradigms for existing constructs (violating the "there should be one obvious way to do it" zen); at worst it would obfuscate the whole language.
If you really see the need for Python macros then a preprocessor would surely be the best way to prove the validity of such ideas?
regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
