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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Why Python doesn't need blocks

40 点作者 ceronman将近 11 年前

14 条评论

jliechti1将近 11 年前
Guido himself has said no multiline lambdas is an explicit design choice, and it&#x27;s not really a technical issue:<p><i>&quot;But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there&#x27;s already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.&quot;</i><p>source: <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=147358" rel="nofollow">http:&#x2F;&#x2F;www.artima.com&#x2F;weblogs&#x2F;viewpost.jsp?thread=147358</a><p>EDIT: This was from an earlier proposal in 2006.
评论 #7966078 未加载
评论 #7965637 未加载
评论 #7965588 未加载
评论 #7965620 未加载
andrewvc将近 11 年前
This is one of those pieces that is simultaneously very correct and very wrong. Technically, it&#x27;s mostly correct, but the fact is Ruby has blocks, lambdas, and the ability to pass around a method attached to an object instance. That gets you a superset of functionality really. It&#x27;s just all syntactic sugar.<p>As a lisper I could easily point my finger at ruby blocks and point out they&#x27;re more complicated than just always using a function, but the fact is, in practice, it just doesn&#x27;t matter. Ruby blocks cover 95% of the cases you hit in a pretty way, and when they don&#x27;t you can still use lambdas!<p>Now macros, those are a better solution to what blocks, but it&#x27;s a 95% solution, so I&#x27;ve stopped caring.
评论 #7966613 未加载
评论 #7965615 未加载
ianbicking将近 11 年前
This article doesn&#x27;t seem to address continue, return, and break. These are control-flow features that are often allowed in blocks (though not all languages) that can&#x27;t be done in a function. That is, in a block &quot;return&quot; will return from the enclosing function, and continue&#x2F;break are a sort of signal to code calling the block. You can simulate the second, like jQuery.each(function (item) {if (timeToStop) return false}); but I don&#x27;t know of good conventions for this so typically the functionality is skipped. But it&#x27;s demonstrably useful functionality because it is so widely present in languages.
otikik将近 11 年前
It seems the author overlooked how `return` works in a block, compared to a function. It was one of the main reasons why Yehuda Katz proposed adding blocks to javascript (I see the reasoning behind it, but I think javascript doesn&#x27;t need more concepts).
评论 #7965964 未加载
jameskilton将近 11 年前
That&#x27;s hardly fair to use the term &quot;any decent language&quot;. Is the author really saying that SmallTalk is not a decent language?<p>Of course Python actually <i>does</i> have blocks (lambda), they&#x27;re just very limited, so it&#x27;s a strange article none-the-less and to a non-Python user come across as a bit of a hack so that you aren&#x27;t constantly passing method pointers around. But maybe that&#x27;s just me.
评论 #7965931 未加载
stdbrouw将近 11 年前
I think the author&#x27;s correct here, there&#x27;s really nothing uniquely wonderful about blocks, but he&#x27;s railing against people that don&#x27;t exist. Pythonistas would like some sort of way to do inline functions, beyond one-liner lambdas, in Python. Whether those are just generic functions or Ruby-inspired blocks is really not all that important. As long as we can inline &#x27;em.
评论 #7965729 未加载
评论 #7965664 未加载
lloeki将近 11 年前
&gt; <i>Promises&#x2F;A has been ported to Ruby, with basically the same API…</i><p>This is, to me, the core of the problem.<p>&gt; <i>The Promises&#x2F;A spec from CommonJS defines Promise.then as taking three (optional) callbacks: fulfilledHandler, errorHandler, and progressHandler. The code above is passing two of them at once.</i><p>Shoehorning things from different realms (e.g desperately trying to write JS in Ruby or vice-versa) is not a good idea.<p>Instead of either:<p><pre><code> db.select_one(sql, thingid) .then((proc {|rowset| rowset[0][&#x27;foo&#x27;}), (proc {|err| log_error(err)})) </code></pre> or:<p><pre><code> db.select_one(sql, thingid) .then {|rowset| rowset[0][&#x27;foo&#x27;} .then(nil) {|err| log_error(err)} </code></pre> Why not do:<p><pre><code> db.select_one(sql, thingid) .then {|rowset| rowset[0][&#x27;foo&#x27;} .else {|err| log_error(err)} .each {|whatever| the_progress(callback_is)} </code></pre> Also, <i>method(:log_error)</i> will happily turn the method into a proc.<p>This last case is actually extremely important. Contrary to what the author claims, functions and methods <i>are</i> first class in Ruby. The problem is that in Ruby&#x27;s grammar an identifier without parentheses is a method call if that identifier does not resolve to a variable. Therefore, you cannot refer to an existing function by its name, merely because it would resolve to a call.<p>Therefore the difference between those is <i>purely syntactic</i>:<p><pre><code> Python Ruby foo method(:foo) foo() foo </code></pre> Also, this[0] explains how <i>&amp;:to_i</i> works, which can be leveraged with great success, should one implement the promise class in a sufficiently idiomatic way (turning the above <i>log_error</i> reference into &amp;:log_error)<p>[0]: <a href="http://ablogaboutcode.com/2012/01/04/the-ampersand-operator-in-ruby/" rel="nofollow">http:&#x2F;&#x2F;ablogaboutcode.com&#x2F;2012&#x2F;01&#x2F;04&#x2F;the-ampersand-operator-...</a>
tbrownaw将近 11 年前
...huh? Having piece-of-code A call piece-of-code B which in turn calls some other piece of code <i>as determined by A</i> is useful. Whether you call this idea a &quot;block&quot; or a &quot;lambda&quot; or a &quot;function pointer&quot; or a &quot;first-class function&quot; is an implementation detail.
dkarapetyan将近 11 年前
Next up: Why we don&#x27;t need higher level abstractions because we can do it all in assembly.
anaphor将近 11 年前
Python already has multi-line lambdas, you just need to be creative <a href="http://ideone.com/ybf63a" rel="nofollow">http:&#x2F;&#x2F;ideone.com&#x2F;ybf63a</a>
true_religion将近 11 年前
If anyone has used block-happy smaltalk, you know how amazing it can be to do dependency injection easily and arbitarily. Almost function you write can be generic, and only become specific when it needs to in the business code.
mpweiher将近 11 年前
Hmm...I am not sure what difference the author is making between closures and blocks, the terms at least overlap substantially.<p>For example, Smalltalk blocks have been &quot;upgraded&quot; to closures in most dialects (and not implementing them as closures in the first place was not a choice of semantics, but one of implementation simplicity).<p>Also, Swift closures <i>are</i> the same as Objective-C blocks.<p><pre><code> +(void)logMe: (void (^)(void))block { NSLog(@&quot;object of class: %@&quot;,[(id)block class]); } </code></pre> Called from Swift with a closure:<p><pre><code> func applicationDidFinishLaunching(aNotification: NSNotification?) { logger.logMe( { } ); } </code></pre> Results in:<p><pre><code> 2014-06-30 19:55:37.973 SwifTest[94782:303] object of class: __NSMallocBlock__ </code></pre> So much ado about nothing?
fdsary将近 11 年前
I was a ruby developer, who then had to do a lot of C and am writing CL&#x2F;Clojure for fun.<p>Then I went back to a ruby project, and realised - the language I used to adore kinda sucks, because it&#x27;s _so_ un-functional.
Arnor将近 11 年前
&gt; JavaScript, for example...<p>What an odd appeal to authority...