TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: How is Python's OOP is superior vs. Lisp CLOS?

30 点作者 stealthcat将近 3 年前
Python classes may be clunky but it is said that Python class system is more flexible than other languages&#x27; OOP, even Lisp CLOS.<p>How does Python class system actually compare to Lisp CLOS?<p>I&#x27;ve seen arguments for Python class system is the blocker for important code optimizations, AOT or JIT. Are there elaborate explanations on why we get near-machine code speed for compiled SBCL Lisp but we cannot even save the image for PyPy runs? Seems like a problem worse than GIL.

13 条评论

e12e将近 3 年前
&gt; (...) it is said that Python class system is more flexible than other languages&#x27; OOP, even Lisp CLOS.<p>Who says this? Python does expose a bit of the plumbing of its class&#x2F;object system - but I can&#x27;t recall seeing anyone calling it especially powerful or flexible?<p>I don&#x27;t think I&#x27;ve seen anyone argue for any object system being strictly more flexible&#x2F;powerful than CLOS.<p>Some, like smalltalk, ruby, Dylan or Javascript original prototype based object system might be useful, simpler subsets of CLOS - and might so arguably be &quot;better&quot;.<p>Afaik much of the problem with python has to do with the language being quite dynamic, and also somewhat complex scope handling.
评论 #31810555 未加载
jake_morrison将近 3 年前
Python&#x27;s OOP is not superior to CLOS. CLOS is very full-featured. Python&#x27;s OO does support features like multiple inheritance, which makes it more sophisticated than e.g. Java.<p>One CLOS feature that is particularly interesting is multi-dispatch. When you call a method, most languages implement polymorphism by looking at the class of the object and call the corresponding method in the class. In CLOS, it looks at all the parameters of the method. This is similar to pattern matching in functional programming languages like Elixir.<p><a href="https:&#x2F;&#x2F;lispcookbook.github.io&#x2F;cl-cookbook&#x2F;clos.html" rel="nofollow">https:&#x2F;&#x2F;lispcookbook.github.io&#x2F;cl-cookbook&#x2F;clos.html</a>
评论 #31810052 未加载
评论 #31809866 未加载
评论 #31809585 未加载
评论 #31815549 未加载
评论 #31809676 未加载
lispm将近 3 年前
&gt; Are there elaborate explanations on why we get near-machine code speed for compiled SBCL Lisp<p>But not for CLOS code. CLOS is a subset of Common Lisp and it addresses flexibility, expressiveness, runtime dynamics AND decent speed. But fully dynamic CLOS code (with added meta-level) will not be &#x27;machine level&#x27; speed.<p>See Julia for a more recent approach to multimethods and performance. There are also CLOS optimizations in the past and some newer approaches -&gt; but these usually lead to less runtime dynamics.
评论 #31809273 未加载
tonyg将近 3 年前
&gt; Python classes may be clunky but it is said that Python class system is more flexible than other languages&#x27; OOP, even Lisp CLOS.<p>Nah. Python&#x27;s metaprotocol is <i>inflexible</i> compared to other similarly-dynamic languages.<p>Here, let&#x27;s try to monkeypatch a method onto a hierarchy of existing classes, calling the superclass method from time to time.<p>First, here&#x27;s our existing hierarchy:<p><pre><code> class Base: pass class Derived(Base): pass </code></pre> This is the decorator that will do the monkeypatching. Any other way of doing the monkeypatching will fall foul of the error we&#x27;re about to see. There&#x27;s no way around it.<p><pre><code> def extend(cls): def extender(f): setattr(cls, f.__name__, f) return f return extender </code></pre> OK, let&#x27;s add `foo` to Base:<p><pre><code> @extend(Base) def foo(self): print(&#x27;I am a base!&#x27;) </code></pre> and to Derived, calling the superclass:<p><pre><code> @extend(Derived) def foo(self): print(&#x27;I am a derived!&#x27;) super().foo() print(&#x27;I am still a derived!&#x27;) </code></pre> Finally, let&#x27;s try it:<p><pre><code> Derived().foo() </code></pre> Oh! What&#x27;s this??<p><pre><code> ~$ python t.py I am a derived! Traceback (most recent call last): File &quot;&#x2F;home&#x2F;tonyg&#x2F;t.py&quot;, line 20, in &lt;module&gt; Derived().foo() File &quot;&#x2F;home&#x2F;tonyg&#x2F;t.py&quot;, line 17, in foo super().foo() RuntimeError: super(): __class__ cell not found </code></pre> Huh!<p>---<p>Turns out in situations like this you have to hold the runtime&#x27;s hand by supplying `super(Derived, self)` instead of `super()` in the `foo` in Derived. It&#x27;s to do with how the compiler statically (!) assigns information about the superclass hierarchy using magic closure variables at compile-time (!).<p>There <i>may</i> be some insane magic tricks one could do to make this work, <i>maybe</i>. Things like reaching into a closure, rebuilding it, adding new slots, preserving existing bindings, avoiding accidental capture, making sure everything lines up just right. It... didn&#x27;t seem like a good idea to put insane magic in production, so I did the traditional Python thing: swallowed my discomfort and pressed on with the stupid workaround for the bad design in order to accomplish something like what I was trying to achieve.
评论 #31809393 未加载
评论 #31809678 未加载
jackdaniel将近 3 年前
I&#x27;ve never heard that Python OOP is any good, not to even mention superior to other contemporary systems (like Java). Could you share the source where it is said that &quot;Python class system is more flexible than other languages&quot;?
评论 #31808916 未加载
gregors将近 3 年前
This is a very leading question. Are you trying to invoke Cunningham&#x27;s Law on purpose? Or just in a very pro-lisp environment that HN is known for? A better question might be to &quot;compare &amp; contrast Python OOP vs Lisp CLOS&quot; I certainly don&#x27;t think Python&#x27;s OOP is superior.
declnz将近 3 年前
&gt; It is said that &lt;x&gt;<p>I for one have never heard that said about Python; if this was on Wikipedia I&#x27;d definitely be mumbling Weasel Word[1] now...<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Weasel_word" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Weasel_word</a>
jasfi将近 3 年前
I prefer Nim&#x27;s approach where you can have objects, but they&#x27;re just variables (properties). The procedures aren&#x27;t tied to objects, but you can pass&#x2F;return objects. To me this is more flexible.<p>I can write OO code as well, this is just personal preference.
akjj将近 3 年前
I think others have addressed the differences between Python&#x27;s class system and CLOS, both of which are very flexible, as I understand.<p>However, as far as optimization, the point is that Python&#x27;s class system is implicated in almost every line of code. Most operators are actually invocations of corresponding &quot;dunder&quot; methods on their operands, which can be potentially changed, and whose invocation is actually surprisingly complicated and difficult to optimize.<p>Common Lisp, of course, does not have operators in the same sense, just functions. However, the analogous functions, like +, *, aref, etc. are not generic functions in the sense of CLOS. They only take built-in data types as arguments and cannot be overloaded. This lack of extensibility makes it easier for the compiler to know what actual code is being invoked and to optimize their use. Arguably, this makes Common Lisp seem like a less flexible language, and in some ways its design does pay more attention to optimization than its reputation would have you believe. On the other hand, the lisp syntax means that there&#x27;s no such thing as a finite set of operators that you&#x27;d want to overload. If you want a different type of multiplication, you can just use a different function.
agumonkey将近 3 年前
Every time I watch a dabeaz talk about metaprogramming python I think about CLOS.<p>Expert may pitch in but it feels like a regression (even though I understand the social dynamics at play)
pjmlp将近 3 年前
Python OOP more flexible than CLOS? Not really.
nahuel0x将近 3 年前
You need to compare Self against CLOS or Smalltalk. Python object system is a poor thought hybrid between prototypes and classes.
bjourne将近 3 年前
No, it is absolutely the opposite. Lisp&#x27;s object system(s) are much more powerful and much more expressive than what Python got. However, that expressiveness comes with a cost; everyone and their grandmother builds their own object system because they are unhappy about some detail in the default object system. Personally, I prefer the Python approach where the object system is coded into the language. Strictly less powerful, but more practical and to me it doesn&#x27;t &quot;feel&quot; very limiting.
评论 #31809614 未加载