python和宏（再次）[是：python3：'where'关键字] [英] python and macros (again) [Was: python3: 'where' keyword]
问题描述
Paul Rubin写道：
宏怎么样？使用C预处理器在C />程序中完成了一些非常糟糕的事情。但是，为了向Python添加卫生宏，还有一个重要的步骤。有什么想法吗？
"运动"看起来有点夸张。也许2-3人进行了一些实验，但核心Python开发人员似乎没有人愿意提倡引入宏。
为什么要关心宏的输出是否丑陋，
如果没有人会看到它？
但至少一些人眼必须看一眼！
< rethorical-question>
你有没有调试过宏？
< / rethorical -question>
更加严格，我已经考虑过这个问题了，而且我非常反对在Python中引入宏。 />
以下是几个原因：
1.我喜欢Lisp中的defmacro。问题是，Lisp是一个基于s表达式的
语言，而Python则不是。我们不能用Python实现defmacro和
，即使我们可以，如果太难看也不能使用（至少，恕我直言）。
2.一个可以在Python中提出卫生模式匹配宏，
类似于
方案语法 - 规则宏。再说一遍，如何以非丑陋的方式在Python中实现模式匹配并不明显。另外，
我觉得卫生的宏非常有限而且不值得付出努力。
3.我们会在Python中添加宏的学习曲线和它们的$>
subtilities我们不想要它。
4.宏会使很多Python模块系统复杂化。
5我们Guido为我们所有人提供了良好的语法，为什么我们应该为它们摆弄？b $ b b b？更严重的是，如果在语言中识别出一些冗长的
（想想装饰者的raison d'etre，对于
实例）我非常喜欢等待Guido照顾
，一劳永逸，而不是基于宏提供100种不同的定制
解决方案。
我相信如果我想多一点，我可以找到其他原因，但这些
应该足够了;）
我想要什么感兴趣的是一个Lisp / Scheme实现
编译为Python字节码，但我不知道任何项目
朝那个方向发展。
Michele Simionato
PS针对该主题感兴趣的人的一些指示：
http：// logix。 livelogix.com/ （一种类似Python的语言宏）
https://sourceforge.net/projects/pymac/ （用于Python的实验性
Dylan启发的宏系统）
mi ********** *****@gmail.com 写道：2.可以在Python中提出卫生模式匹配宏，类似于
Scheme语法规则宏。同样，如何以非丑陋的方式在Python中实现模式匹配并不明显。另外，
我觉得卫生宏非常有限，不值得努力。
如何在Scheme中做到这一点并不明显。
之前已经达成共识。
3.我们会在Python中添加学习曲线宏和他们的潜意识，我们不想要它。
我无法想象它会比我们已经拥有的
__metaclass__的学习曲线更糟糕。如果它是以某种方式完成的，那么我们大多数人只会依赖几个标准的那样，那就没问题。
4.宏会使很多Python模块复杂化系统。
我不知道怎么样，但也许我错过了什么。
5.我们让Guido为我们所有人提供了良好的语法，为什么我们应该摆弄呢？更严重的是，如果语言中识别出一些冗长（想想装饰者的raison d'etre，对于
实例）我非常喜欢等待Guido来照顾<这是一劳永逸的，而不是基于宏的100种不同的定制
解决方案。
每次有些新手问无辜的我怎么......问题，我们
看到大师的令人难以置信的可怕答案。只需查看有关
条件表达式等的常见问题解答。我只是看不到Python语法更改
即将发布。
我想做什么感兴趣的是一个Lisp / Scheme实现
编译为Python字节码，但我不知道那个方向的任何项目。
但这听起来像是一个奇怪的想法。 Python字节码只是一个
CPython工件，不是语言的一部分。它甚至不是很好的神器。好的Lisp / Scheme实现编译为原生的
代码，它击败了CPython字节码。如果有一个Python实现可以编译Python到/ b $ b $ S表达式然后让一个高性能的Lisp或Scheme系统
$ b，那将会更有意义。 $ b负责其余部分。
Paul Rubin：michele.simion ... @ gmail.com写道：
< about scheme macros>
如何在Scheme中做到这一点并不明显。在达成共识之前，有一些头脑刮擦和实验性实施。
实际上我还不相信已经达成共识，即有一个不可忽视的少数计划者确信原来的Lisp
宏更好，不谈常见的lispers;）
3.我们会在Python中添加宏的学习曲线和它们的子实用程序，我们不想要它。
我无法想象它比我们已经拥有的
__metaclass__的学习曲线更糟糕。
对我来说，学习宏*和他们的subtilities *比学习元类要困难得多
。
4.宏将会使很多Python模块系统复杂化。
我不知道怎么样，但也许我错过了什么。
转到comp.lang.scheme并谷歌搜索宏和模块系统;
你会得到你想知道的一切等等！
5.我们让Guido为我们所有人提供了良好的语法，为什么我们应该让b $ b b摆弄呢？更严重的是，如果语言中识别出一些冗长（想想装饰者的raison d'etre，对于
实例）我非常喜欢等待Guido来照顾<这是一劳永逸的，而不是基于宏的100种不同的定制
解决方案。
每次有些新手问无辜的我怎么......问题，我们看到大师们难以置信的可怕答案。只需查看关于
条件表达式等的常见问题解答，我就不会看到Python语法的变化即将发布。
好吧，我认为这是一个积极的事实。如果设计了一个语法（比如
a三元
运算符），那么拥有它比拥有一个
$ b $更好*不* b百定制
制作语法。最后，我们在这里谈论语法糖，
不是关于
缺乏功能。
我感兴趣的是一个Lisp / Scheme实现
编译成Python字节码，但我不知道那个方向上的任何项目。
但这听起来像一个奇怪的想法。 Python字节码只是一个CPython工件，不是语言的一部分。它甚至不是好神器。好的Lisp / Scheme实现编译为本机代码，可以胜过CPython字节码。如果有一个Python实现将Python编译为S表达式，然后让高性能的Lisp或Scheme系统处理剩下的工作，那将会更有意义。
如果你想让Python运行得更快，这是一个奇怪的想法。它不是那么奇怪
如果你想要的是从
相同的意义上从Lisp / Scheme访问Python
Jython可以访问Java。
Michele Simionato
mi *************** @ gmail.com 写道：
< blockquote class =post_quotes>如果你想让Python运行得更快，这是一个奇怪的想法。如果你想要的是从Lisp / Scheme获得Python的同样意义上的Jython可以访问Java，那就不那么奇怪了。
如果您更喜欢编写Lisp代码（或者如果需要可以使用
）并且在跨平台环境中运行它，这听起来非常好。
几乎可以在任何地方使用，并且可以访问大型标准库
现代公用事业。
br，
S
Paul Rubin wrote:
How about macros? Some pretty horrible things have been done in C
programs with the C preprocessor. But there''s a movememnt afloat to
add hygienic macros to Python. Got any thoughts about that?
"Movement" seems quite an exaggeration. Maybe 2-3 people made some
experiments, but nobody within the core Python developers seems
to be willing to advocate the introduction of macros.
Why should you care whether the output of a macro is ugly or not,
if no human is ever going to look at it?
But at least some human eye have to look at it!
<rethorical-question>
Did you ever debug a macro?
</rethorical-question>
More seriuosly, I have given some thought to the issue, and I am very
much against the introduction of macros in Python.
Here are a few reasons:
1. I like defmacro in Lisp. Problem is, Lisp is an s-expression based
language, Python is not. We cannot implement defmacro in Python and
even if we could, if would be too ugly to be used (at least, IMHO).
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.
3. We would add to Python the learning curve of macros and their
subtilities and we do not want it.
4. Macros would complicate a lot Python module system.
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.
I am sure I could find other reasons if I think a bit more, but these
should suffice for the moment ;)
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.
Michele Simionato
P.S. some pointers for people interested on the topic:
http://logix.livelogix.com/ (a Python-like language with macros)
https://sourceforge.net/projects/pymac/ (an experimental
Dylan-inspired macro system for Python)
mi***************@gmail.com 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.
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.
Paul Rubin:michele.simion...@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
mi***************@gmail.com writes:
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.
And it sounds very nice if you prefer writing Lisp code (or resort to
it if needed) and run it on a cross-platform environment that''s
available almost everywhere, and access a large standard library of
modern utilities.
br,
S
这篇关于python和宏（再次）[是：python3：'where'关键字]的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
