python - ruby用途 - ruby程式




Ruby不具備Python的功能,反之亦然? (20)

有很多關於Python和Ruby的討論,我都發現它們完全沒有幫助,因為它們都反過來說明為什麼特性X在語言Y中很糟糕,或者說聲明語言Y沒有X,儘管事實上它確實如此。 我也確切知道為什麼我更喜歡Python,但這也是主觀的,並且不會幫助任何人選擇,因為他們可能沒有像我一樣的開發口味。

客觀地列出這些差異是很有趣的。 所以沒有“Python的lambdas糟糕”。 相反,請解釋一下Ruby的lambda表達式可以做到Python不能做到的事情。 沒有主觀性。 示例代碼很好!

請不要在一個答案中有幾處不同。 並且投票你知道的是正確的,並且那些你知道的是不正確的(或者是主觀的)。 另外,語法上的差異並不令人感興趣。 我們知道Python會使用縮進的方式來處理括號和結尾,而在Python中@被稱為self。

更新:現在這是一個社區維基,所以我們可以在這裡添加巨大的差異。

Ruby在類體中有一個類引用

在Ruby中,你已經在類體中引用了類(self)。 在Python中,只有在類構造完成之後,才能引用該類。

一個例子:

class Kaka
  puts self
end

在這種情況下,自己就是班級,這段代碼會打印出“卡卡”。 無法打印出類名或以其他方式從Python中的類定義主體(方法定義外部)訪問該類。

所有類在Ruby中都是可變的

這使您可以開發核心類的擴展。 這是一個軌道擴展的例子:

class String
  def starts_with?(other)
    head = self[0, other.length]
    head == other
  end
end

Python(想像沒有''.startswith方法):

def starts_with(s, prefix):
    return s[:len(prefix)] == prefix

你可以在任何序列上使用它(不僅僅是字符串)。 為了使用它,你應該明確地導入它,例如, from some_module import starts_with

Ruby具有像Perl一樣的腳本功能

Ruby具有第一類正則表達式,$ -variables,awk / perl逐行輸入循環和其他功能,使其更適合編寫嵌入文本文件的小型shell腳本或充當其他程序的粘合代碼。

Ruby有一流的延續

感謝callcc聲明。 在Python中,您可以通過各種技術創建延續,但不支持內置的語言。

Ruby有塊

使用“do”語句,您可以在Ruby中創建一個多行匿名函數,它將作為參數傳入到do前面的方法中,並從那裡調用。 在Python中,您可以通過傳遞方法或使用生成器來完成此操作。

紅寶石:

amethod { |here|
    many=lines+of+code
    goes(here)
}

Python(Ruby塊對應於Python中的不同構造):

with amethod() as here: # `amethod() is a context manager
    many=lines+of+code
    goes(here)

要么

for here in amethod(): # `amethod()` is an iterable
    many=lines+of+code
    goes(here)

要么

def function(here):
    many=lines+of+code
    goes(here)

amethod(function)     # `function` is a callback

有趣的是,Ruby中用於調用塊的便利語句被稱為“yield”,它在Python中將創建一個生成器。

紅寶石:

def themethod
    yield 5
end

themethod do |foo|
    puts foo
end

蟒蛇:

def themethod():
    yield 5

for foo in themethod():
    print foo

雖然原理不同,但結果卻非常相似。

Ruby更容易支持函數式(管道式)編程

myList.map(&:description).reject(&:empty?).join("\n")

蟒蛇:

descriptions = (f.description() for f in mylist)
"\n".join(filter(len, descriptions))

Python有內置的生成器(像上面提到的那樣使用Ruby塊)

Python支持語言中的生成器。 在Ruby 1.8中,您可以使用生成器模塊,它使用continuation從塊中創建生成器。 或者,你可以使用塊/ proc / lambda! 而且,在Ruby 1.9中,Fibers是並且可以用作生成器,而Enumerator類是一個內置的生成器4

docs.python.org有這個生成器的例子:

def reverse(data):
    for index in range(len(data)-1, -1, -1):
        yield data[index]

將此與上面的塊示例進行對比。

Python具有靈活的名稱空間處理

在Ruby中,當你導入一個帶有require的文件時,那個文件中定義的所有東西都將在你的全局命名空間中結束。 這會導致命名空間污染。 解決方案是Rubys模塊。 但是,如果使用模塊創建名稱空間,則必須使用該名稱空間來訪問所包含的類。

在Python中,該文件是一個模塊,您可以使用from themodule import *導入其包含的名稱,從而如果需要則會污染命名空間。 但是,您也可以使用from themodule import aname, another導入選定的名稱,也可以只import themodule ,然後使用import themodule訪問名稱。 如果你想在你的命名空間中有更多的級別,你可以使用包,它們是帶有模塊和__init__.py文件的目錄。

Python有文檔

文檔字符串是附加到模塊,函數和方法的字符串,並且可以在運行時進行內省。 這有助於創建諸如幫助命令和自動文檔之類的內容。

def frobnicate(bar):
    """frobnicate takes a bar and frobnicates it

       >>> bar = Bar()
       >>> bar.is_frobnicated()
       False
       >>> frobnicate(bar)
       >>> bar.is_frobnicated()
       True
    """

Ruby的等價物與javadocs類似,位於方法的上方而不是其內部。 通過使用1.9的Method#source_location 示例用法,可以在運行時從文件中檢索它們

Python有多重繼承

Ruby沒有(“故意” - 請參閱Ruby的網站, 在這裡看看它是如何在Ruby中完成的 )。 它確實將模塊概念重用為一種抽像類。

Python有list / dict理解

蟒蛇:

res = [x*x for x in range(1, 10)]

紅寶石:

res = (0..9).map { |x| x * x }

蟒蛇:

>>> (x*x for x in range(10))
<generator object <genexpr> at 0xb7c1ccd4>
>>> list(_)
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

紅寶石:

p = proc { |x| x * x }
(0..9).map(&p)

Python 2.7+

>>> {x:str(y*y) for x,y in {1:2, 3:4}.items()}
{1: '4', 3: '16'}

紅寶石:

>> Hash[{1=>2, 3=>4}.map{|x,y| [x,(y*y).to_s]}]
=> {1=>"4", 3=>"16"}

Python有裝飾器

類似於裝飾器的東西也可以在Ruby中創建,也可以認為它們不像Python中那樣必要。

語法差異

Ruby需要“結束”或“}”來關閉它的所有範圍,而Python只使用空白。 最近在Ruby中嘗試僅允許空格縮進http://github.com/michaeledgar/seamless


In Ruby, when you import a file with require, all the things defined in that file will end up in your global namespace.

通過Cargo您可以“ 不需要混淆名稱空間就可以使用 ”。

# foo-1.0.0.rb
class Foo
  VERSION = "1.0.0"
end

# foo-2.0.0.rb
class Foo
  VERSION = "2.0.0"
end
>> Foo1 = import("foo-1.0.0")
>> Foo2 = import("foo-2.0.0")
>> Foo1::VERSION
=> "1.0.0"
>> Foo2::VERSION
=> "2.0.0"

Python示例

函數是Python中的第一類變量。 您可以聲明一個函數,將其作為對像傳遞並覆蓋它:

def func(): print "hello"
def another_func(f): f()
another_func(func)

def func2(): print "goodbye"
func = func2

這是現代腳本語言的基本特徵。 JavaScript和Lua也是這樣做的。 Ruby不以這種方式處理函數; 命名一個函數調用它。

當然,有些方法可以在Ruby中做這些事情,但它們不是一流的操作。 例如,你可以使用Proc.new封裝一個函數,將它作為一個變量來處理 - 但它不再是一個函數; 它是一個帶有“調用”方法的對象。

Ruby的函數不是一流的對象

Ruby函數不是一流的對象。 函數必須包裝在一個對像中以傳遞它們; 結果的對像不能像一個函數一樣對待。 功能不能以一流的方式分配; 相反,必須調用其容器對像中的函數來修改它們。

def func; p "Hello" end
def another_func(f); method(f)[] end
another_func(:func)      # => "Hello"

def func2; print "Goodbye!"
self.class.send(:define_method, :func, method(:func2))
func                     # => "Goodbye!"

method(:func).owner      # => Object
func                     # => "Goodbye!"
self.func                # => "Goodbye!"    

Python有一個“我們都是大人”的心態。 因此,你會發現Ruby具有類似常量的東西,而Python不具備這種功能(儘管Ruby的常量只會引發警告)。 Python的思維方式是,如果你想使某些東西保持不變,你應該把變量名放在所有大寫字母中,而不要改變它。

例如,Ruby:

>> PI = 3.14
=> 3.14
>> PI += 1
(irb):2: warning: already initialized constant PI
=> 4.14

蟒蛇:

>>> PI = 3.14
>>> PI += 1
>>> PI
4.1400000000000006

Python有一個明確的內置語法,用於列表擴展和生成器,而在Ruby中則使用map和代碼塊。

比較

list = [ x*x for x in range(1, 10) ]

res = (1..10).map{ |x| x*x }

Ruby對Python的支持是它的腳本語言功能。 腳本語言在這種情況下意味著用於shell腳本中的“膠合代碼”和一般的文本操作。

這些大多數與Perl共享。 一流的內置正則表達式,$ -Variables,有用的命令行選項,如Perl(-a,-e)等

再加上其簡潔而又不失代表性的語法,這對於這些任務來說是完美的。

Python對我來說更多的是一種動態類型的商業語言,它非常容易學習,並且語法簡潔。 不像Ruby那麼“酷”,但整潔。 Python對我來說有什麼是其他庫的大量綁定。 綁定到Qt和其他GUI庫,許多遊戲支持庫和和。 Ruby少得多。 雖然很多使用的綁定例如數據庫質量很好,但我發現在Python中更好地支持小眾庫,即使對於同一個庫也有一個Ruby綁定。

所以,我會說兩種語言都有它的用處,而且它的任務是定義使用哪一種語言。 兩者都很容易學習。 我並排使用它們。 用於腳本的Ruby和用於獨立應用程序的Python。



無恥複製/粘貼: Alex Martelli從comp.lang.python郵件列表中回答Ruby比Python更好 ”的主題。

2003年8月18日上午10點50分Erik Max Francis寫道:

“Brandon J. Van Every”寫道:

Ruby比Python更好? 我確定有什麼。 它是什麼?

問問Ruby這個人而不是Python人會更有意義嗎?

根據用戶的目的,可能會或可能不會,例如,如果用戶的目的包括Python社區的“社會學研究”,那麼向該社區提出問題可能會更多地揭示關於它的信息,而不是將它們放在其他地方:-)。

Personally, I gladly took the opportunity to follow Dave Thomas' one-day Ruby tutorial at last OSCON. Below a thin veneer of syntax differences, I find Ruby and Python amazingly similar -- if I was computing the minimum spanning tree among just about any set of languages, I'm pretty sure Python and Ruby would be the first two leaves to coalesce into an intermediate node:-).

Sure, I do get weary, in Ruby, of typing the silly "end" at the end of each block (rather than just unindenting) -- but then I do get to avoid typing the equally-silly ':' which Python requires at the start of each block, so that's almost a wash:-). Other syntax differences such as '@foo' versus 'self.foo', or the higher significance of case in Ruby vs Python, are really just about as irrelevant to me.

Others no doubt base their choice of programming languages on just such issues, and they generate the hottest debates -- but to me that's just an example of one of Parkinson's Laws in action (the amount on debate on an issue is inversely proportional to the issue's actual importance).

Edit (by AM 6/19/2010 11:45): this is also known as "painting the bikeshed" (or, for short, "bikeshedding") -- the reference is, again, to Northcote Parkinson, who gave "debates on what color to paint the bikeshed" as a typical example of "hot debates on trivial topics". (end-of-Edit).

One syntax difference that I do find important, and in Python's favor -- but other people will no doubt think just the reverse -- is "how do you call a function which takes no parameters". In Python (like in C), to call a function you always apply the "call operator" -- trailing parentheses just after the object you're calling (inside those trailing parentheses go the args you're passing in the call -- if you're passing no args, then the parentheses are empty). This leaves the mere mention of any object, with no operator involved, as meaning just a reference to the object -- in any context, without special cases, exceptions, ad-hoc rules, and the like. In Ruby (like in Pascal), to call a function WITH arguments you pass the args (normally in parentheses, though that is not invariably the case) -- BUT if the function takes no args then simply mentioning the function implicitly calls it. This may meet the expectations of many people (at least, no doubt, those whose only previous experience of programming was with Pascal, or other languages with similar "implicit calling", such as Visual Basic) -- but to me, it means the mere mention of an object may EITHER mean a reference to the object, OR a call to the object, depending on the object's type -- and in those cases where I can't get a reference to the object by merely mentioning it I will need to use explicit "give me a reference to this, DON'T call it!" operators that aren't needed otherwise. I feel this impacts the "first-classness" of functions (or methods, or other callable objects) and the possibility of interchanging objects smoothly. Therefore, to me, this specific syntax difference is a serious black mark against Ruby -- but I do understand why others would thing otherwise, even though I could hardly disagree more vehemently with them:-).

Below the syntax, we get into some important differences in elementary semantics -- for example, strings in Ruby are mutable objects (like in C++), while in Python they are not mutable (like in Java, or I believe C#). Again, people who judge primarily by what they're already familiar with may think this is a plus for Ruby (unless they're familiar with Java or C#, of course:-). Me, I think immutable strings are an excellent idea (and I'm not surprised that Java, independently I think, reinvented that idea which was already in Python), though I wouldn't mind having a "mutable string buffer" type as well (and ideally one with better ease-of-use than Java's own "string buffers"); and I don't give this judgment because of familiarity -- before studying Java, apart from functional programming languages where all data are immutable, all the languages I knew had mutable strings -- yet when I first saw the immutable-string idea in Java (which I learned well before I learned Python), it immediately struck me as excellent, a very good fit for the reference-semantics of a higher level programming language (as opposed to the value-semantics that fit best with languages closer to the machine and farther from applications, such as C) with strings as a first-class, built-in (and pretty crucial) data type.

Ruby does have some advantages in elementary semantics -- for example, the removal of Python's "lists vs tuples" exceedingly subtle distinction. But mostly the score (as I keep it, with simplicity a big plus and subtle, clever distinctions a notable minus) is against Ruby (eg, having both closed and half-open intervals, with the notations a..b and a...b [anybody wants to claim that it's obvious which is which?-)], is silly -- IMHO, of course!). Again, people who consider having a lot of similar but subtly different things at the core of a language a PLUS, rather than a MINUS, will of course count these "the other way around" from how I count them:-).

Don't be misled by these comparisons into thinking the two languages are very different, mind you. They aren't. But if I'm asked to compare "capelli d'angelo" to "spaghettini", after pointing out that these two kinds of pasta are just about undistinguishable to anybody and interchangeable in any dish you might want to prepare, I would then inevitably have to move into microscopic examination of how the lengths and diameters imperceptibly differ, how the ends of the strands are tapered in one case and not in the other, and so on -- to try and explain why I, personally, would rather have capelli d'angelo as the pasta in any kind of broth, but would prefer spaghettini as the pastasciutta to go with suitable sauces for such long thin pasta forms (olive oil, minced garlic, minced red peppers, and finely ground anchovies, for example - but if you sliced the garlic and peppers instead of mincing them, then you should choose the sounder body of spaghetti rather than the thinner evanescence of spaghettini, and would be well advised to forego the achovies and add instead some fresh spring basil [or even -- I'm a heretic...! -- light mint...] leaves -- at the very last moment before serving the dish). Ooops, sorry, it shows that I'm traveling abroad and haven't had pasta for a while, I guess. But the analogy is still pretty good!-)

So, back to Python and Ruby, we come to the two biggies (in terms of language proper -- leaving the libraries, and other important ancillaries such as tools and environments, how to embed/extend each language, etc, etc, out of it for now -- they wouldn't apply to all IMPLEMENTATIONS of each language anyway, eg, Jython vs Classic Python being two implementations of the Python language!):

  1. Ruby's iterators and codeblocks vs Python's iterators and generators;

  2. Ruby's TOTAL, unbridled "dynamicity", including the ability
    to "reopen" any existing class, including all built-in ones, and change its behavior at run-time -- vs Python's vast but bounded dynamicity, which never changes the behavior of existing built-in classes and their instances.

Personally, I consider 1 a wash (the differences are so deep that I could easily see people hating either approach and revering the other, but on MY personal scales the pluses and minuses just about even up); and 2 a crucial issue -- one that makes Ruby much more suitable for "tinkering", BUT Python equally more suitable for use in large production applications. It's funny, in a way, because both languages are so MUCH more dynamic than most others, that in the end the key difference between them from my POV should hinge on that -- that Ruby "goes to eleven" in this regard (the reference here is to "Spinal Tap", of course). In Ruby, there are no limits to my creativity -- if I decide that all string comparisons must become case-insensitive, I CAN DO THAT ! Ie, I can dynamically alter the built-in string class so that a = "Hello World" b = "hello world" if a == b print "equal!\n" else print "different!\n" end WILL print "equal". In python, there is NO way I can do that. For the purposes of metaprogramming, implementing experimental frameworks, and the like, this amazing dynamic ability of Ruby is extremely appealing. BUT -- if we're talking about large applications, developed by many people and maintained by even more, including all kinds of libraries from diverse sources, and needing to go into production in client sites... well, I don't WANT a language that is QUITE so dynamic, thank you very much. I loathe the very idea of some library unwittingly breaking other unrelated ones that rely on those strings being different -- that's the kind of deep and deeply hidden "channel", between pieces of code that LOOK separate and SHOULD BE separate, that spells death in large-scale programming. By letting any module affect the behavior of any other "covertly", the ability to mutate the semantics of built-in types is just a BAD idea for production application programming, just as it's cool for tinkering.

If I had to use Ruby for such a large application, I would try to rely on coding-style restrictions, lots of tests (to be rerun whenever ANYTHING changes -- even what should be totally unrelated...), and the like, to prohibit use of this language feature. But NOT having the feature in the first place is even better, in my opinion -- just as Python itself would be an even better language for application programming if a certain number of built-ins could be "nailed down", so I KNEW that, eg, len("ciao") is 4 (rather than having to worry subliminally about whether somebody's changed the binding of name 'len' in the builtins module...). I do hope that eventually Python does "nail down" its built-ins.

But the problem's minor, since rebinding built-ins is quite a deprecated as well as a rare practice in Python. In Ruby, it strikes me as major -- just like the too powerful macro facilities of other languages (such as, say, Dylan) present similar risks in my own opinion (I do hope that Python never gets such a powerful macro system, no matter the allure of "letting people define their own domain-specific little languages embedded in the language itself" -- it would, IMHO, impair Python's wonderful usefulness for application programming, by presenting an "attractive nuisance" to the would-be tinkerer who lurks in every programmer's heart...).

亞歷克斯


Another difference in lambdas between Python and Ruby is demonstrated by Paul Graham's Accumulator Generator problem. Reprinted here:

Write a function foo that takes a number n and returns a function that takes a number i, and returns n incremented by i. Note: (a) that's number, not integer, (b) that's incremented by, not plus.

In Ruby, you can do this:

def foo(n)
  lambda {|i| n += i }
end

In Python, you'd create an object to hold the state of n:

class foo(object):
    def __init__(self, n):
        self.n = n
    def __call__(self, i):
        self.n += i
        return self.n

Some folks might prefer the explicit Python approach as being clearer conceptually, even if it's a bit more verbose. You store state like you do for anything else. You just need to wrap your head around the idea of callable objects. But regardless of which approach one prefers aesthetically, it does show one respect in which Ruby lambdas are more powerful constructs than Python's.


I would like to mention Python descriptor API that allows one customize object-to-attribute "communication". It is also noteworthy that, in Python, one is free to implement an alternative protocol via overriding the default given through the default implementation of the __getattribute__ method. Let me give more details about the aforementioned. Descriptors are regular classes with __get__ , __set__ and/or __delete__ methods. When interpreter encounters something like anObj.anAttr , the following is performed:

  • __getattribute__ method of anObj is invoked
  • __getattribute__ retrieves anAttr object from the class dict
  • it checks whether abAttr object has __get__ , __set__ or __delete__ callable objects
  • the context (ie, caller object or class, and value, instead of the latter, if we have setter) is passed to the callable object
  • the result is returned.

As was mentioned, this is the default behavior. One is free to change the protocol by re-implementing __getattribute__ .

This technique is lot more powerful than decorators.


I'm unsure of this, so I add it as an answer first.

Python treats unbound methods as functions

That means you can call a method either like theobject.themethod() or by TheClass.themethod(anobject) .

Edit: Although the difference between methods and functions is small in Python, and non-existant in Python 3, it also doesn't exist in Ruby, simply because Ruby doesn't have functions. When you define functions, you are actually defining methods on Object.

But you still can't take the method of one class and call it as a function, you would have to rebind it to the object you want to call on, which is much more obstuse.


Python has docstrings and ruby doesn't... Or if it doesn't, they are not accessible as easily as in python.

PS。 If im wrong, pretty please, leave an example? I have a workaround that i could monkeypatch into classes quite easily but i'd like to have docstring kinda of a feature in "native way".


Ruby has a line by line loop over input files (the '-n' flag) from the commandline so it can be used like AWK. This Ruby one-liner:

ruby -ne 'END {puts $.}'

will count lines like the AWK one-liner:

awk 'END{print NR}'

Ruby gets feature this through Perl, which took it from AWK as a way of getting sysadmins on board with Perl without having to change the way they do things.


Ruby has embedded documentation:

 =begin

 You could use rdoc to generate man pages from this documentation

 =end

Ruby has sigils and twigils, Python doesn't.

Edit : And one very important thing that I forgot (after all, the previous was just to flame a little bit :-p):

Python has a JIT compiler ( Psyco ), a sightly lower level language for writing faster code ( Pyrex ) and the ability to add inline C++ code ( Weave ).


Syntax is not a minor thing, it has a direct impact on how we think. It also has a direct effect on the rules we create for the systems we use. As an example we have the order of operations because of the way we write mathematical equations or sentences. The standard notation for mathematics allows people to read it more than one way and arrive at different answers given the same equation. If we had used prefix or postfix notation we would have created rules to distinguish what the numbers to be manipulated were rather than only having rules for the order in which to compute values.

The standard notation makes it plain what numbers we are talking about while making the order in which to compute them ambiguous. Prefix and postfix notation make the order in which to compute plain while making the numbers ambiguous. Python would already have multiline lambdas if it were not for the difficulties caused by the syntactic whitespace. (Proposals do exist for pulling this kind of thing off without necessarily adding explicit block delimiters.)

I find it easier to write conditions where I want something to occur if a condition is false much easier to write with the unless statement in Ruby than the semantically equivalent "if-not" construction in Ruby or other languages for example. If most of the languages that people are using today are equal in power, how can the syntax of each language be considered a trivial thing? After specific features like blocks and inheritance mechanisms etc. syntax is the most important part of a language,hardly a superficial thing.

What is superficial are the aesthetic qualities of beauty that we ascribe to syntax. Aesthetics have nothing to do with how our cognition works, syntax does.


You can have code in the class definition in both Ruby and Python. However, in Ruby you have a reference to the class (self). In Python you don't have a reference to the class, as the class isn't defined yet.

An example:

class Kaka
  puts self
end

self in this case is the class, and this code would print out "Kaka". There is no way to print out the class name or in other ways access the class from the class definition body in Python.


在基礎設施方面更多一點:

  • Python比C ++(通過像Boost.PythonSIPPy++這樣的東西)要好得多,與Ruby相比,這些選項似乎要直接針對Ruby解釋器API編寫(當然也可以使用Python編寫,但是在這兩種情況下都是低級的,單調乏味的和容易出錯的),或者使用SWIG(儘管它的工作原理,如果你想支持很多語言,它肯定是非常棒的,但並不像Boost.Python或SIP那麼好)你特別期待綁定C ++)。

  • Python有許多Web應用程序環境(Django,Pylons / Turbogears,web.py,可能至少有六十個),而Ruby(有效)有一個:Rails。 (其他Ruby Web框架確實存在,但似乎很難獲得對Rails的強大支持)。 這方面是好還是壞? 很難說,也許很主觀; 我可以很容易地想像出Python的情況更好,Ruby情況更好的論點。

  • 在文化上,Python和Ruby社區似乎有些不同,但我只能暗示這一點,因為我沒有那麼多與Ruby社區進行交互的經驗。 我主要是希望能夠在兩者上有豐富經驗的人能夠放大(或拒絕)這種說法。


從Ruby的website

相似之處與Python一樣,在Ruby中,......

  • 有一個交互式提示(稱為irb)。
  • 您可以在命令行上閱讀文檔(使用ri命令而不是pydoc)。
  • 沒有特殊的行結束符(通常的換行符除外)。
  • 字符串文字可以像Python的三重引號字符串一樣跨越多行。
  • 括號是用於列表的,括號是用於字典的(在Ruby中稱為“哈希”)。
  • 數組的工作原理是相同的(添加它們會生成一個長數組,但像這樣組成它們a3 = [ a1, a2 ]將為您提供一組數組)。
  • 對像是強類型和動態類型的。
  • 一切都是一個對象,變量只是對象的引用。
  • 雖然關鍵字有點不同,但例外情況也是如此。
  • 你有嵌入式文檔工具(Ruby的稱為rdoc)。

差異與Python不同,在Ruby中,...

  • 字符串是可變的。
  • 您可以創建常量(您不打算改變其值的變量)。
  • 有一些強制性的病例約定(例如,類名以大寫字母開頭,變量以小寫字母開頭)。
  • 只有一種列表容器(一個Array),它是可變的。
  • 雙引號字符串允許使用轉義序列(如\ t)和特殊的“表達式替換”語法(它允許您將Ruby表達式的結果直接插入到其他字符串中,而無需“添加”+“字符串”+“在一起”) 。 單引號字符串就像Python的r“原始字符串”。
  • 沒有“新風格”和“舊風格”的課程。 只是一種。
  • 你永遠不會直接訪問屬性。 有了Ruby,這就是所有的方法調用。
  • 方法調用的括號通常是可選的。
  • 有public,private和protected來強制訪問,而不是Python的_voluntary_ underscore __convention__
  • “mixin's”被用來代替多重繼承。
  • 您可以添加或修改內置類的方法。 這兩種語言都可以讓你在任何時候打開和修改類,但是Python可以防止修改內建函數 - Ruby不會。
  • 你有true和false而不是True和False(而不是None)。
  • 當對真相進行測試時,只有虛假和零評估為虛假值。 其他一切都是真實的(包括0,0.0,“”和[])。
  • 這是elifif而不是elif。
  • 這是需要而不是導入。 否則,使用情況是相同的。
  • 上面的行上的常用樣式註釋(而不是下面的文檔字符串)用於生成文檔。
  • 有許多捷徑,雖然讓你更記住,但你很快就會學習。 他們傾向於使Ruby變得有趣並且非常有效率。

我不認為“Ruby有X和Python不能,而Python有Y和Ruby不是”是最有用的方式來看待它。 他們語言很相似,有很多共同的能力。

在很大程度上,區別在於語言的優雅和可讀性。 要使用你提出的一個例子,理論上兩者都有lambda表達式,但是Python程序員傾向於避免它們,而使用它們的結構看起來並不像Ruby中那樣可讀或慣用。 所以在Python中,一個好的程序員會想要採取不同的途徑來解決這個問題,而不是他在Ruby中的問題,僅僅因為它實際上更好的方法。


我想提出一個原始問題的變體,“Ruby不具有Python的功能,反之亦然?” 它承認了令人失望的答案:“那麼,你可以用Ruby或Python做什麼,而Intercal無法做到呢?” 在那個層面上什麼都沒有,因為Python和Ruby都是龐大王室的一部分,坐擁圖靈的近似位置。

但是這個怎麼樣:

在Ruby中無法用這樣美觀和優秀的工程來完成Python的優雅和完美的工作,反之亦然?

這可能比純粹的功能比較更有趣。





ruby