有很多关于Python和Ruby的讨论，我都发现它们完全没有帮助，因为它们都围绕着为什么X特性在Y语言中很糟糕，或者声称Y语言没有X，尽管事实上它有。我也确切地知道为什么我更喜欢Python，但这也是主观的，对任何人的选择都没有帮助，因为他们可能与我在开发方面的品味不同。
因此，客观地列出这些差异将是有趣的。所以没有“Python的lambdas很糟糕”。相反，解释Ruby的lambda能做而Python不能做的事情。没有主体性。示例代码很好!
请不要在一个答案上有几个不同之处。然后给你认为正确的选项投票，把你认为不正确的(或主观的)选项投下。此外，语法上的差异也不有趣。我们知道Python对缩进的处理就像Ruby对括号和结束的处理一样，@在Python中被称为self。
更新:现在这是一个社区维基，所以我们可以在这里添加大的区别。
Ruby在类主体中有一个类引用
在Ruby中，类主体中已经有了对类(self)的引用。在Python中，直到类构造完成之后才有对类的引用。
一个例子:
class Kaka
puts self
end
self在本例中是类，这段代码将打印出“Kaka”。在Python中，无法打印类名或以其他方式从类定义体(在方法定义之外)访问类。
Ruby中所有的类都是可变的
这使您可以开发核心类的扩展。下面是一个rails扩展的例子:
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
你可以在任何序列上使用它(不仅仅是字符串)。为了使用它，你应该显式地导入它，例如，从some_module import starts_with。
Ruby具有类似perl的脚本功能
Ruby拥有一流的regexp、$-variables、awk/perl逐行输入循环和其他特性，这些特性使它更适合编写小型shell脚本，这些脚本可以转换文本文件或充当其他程序的粘合代码。
Ruby具有一流的延续
多亏了callcc语句。在Python中，您可以通过各种技术创建continuation，但语言中没有内置的支持。
Ruby有块
通过“do”语句，您可以在Ruby中创建一个多行匿名函数，该函数将作为参数传递到do前面的方法中，并从那里调用。在Python中，您可以通过传递方法或使用生成器来完成此操作。
Ruby:
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)
Or
for here in amethod(): # `amethod()` is an iterable
many=lines+of+code
goes(here)
Or
def function(here):
many=lines+of+code
goes(here)
amethod(function) # `function` is a callback
有趣的是，在Ruby中调用块的方便语句称为“yield”，在Python中它将创建一个生成器。
Ruby:
def themethod
yield 5
end
themethod do |foo|
puts foo
end
Python:
def themethod():
yield 5
for foo in themethod():
print foo
尽管原理不同，结果却惊人地相似。
Ruby更容易支持函数式(类管道)编程
myList.map(&:description).reject(&:empty?).join("\n")
Python:
descriptions = (f.description() for f in mylist)
"\n".join(filter(len, descriptions))
Python有内置生成器(如上所述，像Ruby块一样使用)
Python支持该语言中的生成器。在Ruby 1.8中，您可以使用generator模块，该模块使用continuation从块中创建生成器。或者，你可以使用block/proc/lambda!此外，在Ruby 1.9中，光纤可以用作生成器，并且枚举器类是一个内置生成器4
Docs.python.org有这样一个生成器示例:
def reverse(data):
for index in range(len(data)-1, -1, -1):
yield data[index]
将其与上面的块示例进行对比。
Python具有灵活的名称空间处理
在Ruby中，当您使用require导入文件时，该文件中定义的所有内容都将在全局名称空间中结束。这会导致名称空间污染。解决方案就是ruby模块。但是如果使用模块创建名称空间，则必须使用该名称空间访问包含的类。
在Python中，该文件是一个模块，您可以从模块import *中导入其包含的名称，从而污染命名空间。但是你也可以从模块import aname中导入选定的名称，或者你可以简单地导入模块，然后使用module.aname访问这些名称。如果你想在你的命名空间中有更多的层，你可以有包，包是包含模块和__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有列表/字典推导式
Python:
res = [x*x for x in range(1, 10)]
Ruby:
res = (0..9).map { |x| x * x }
Python:
>>> (x*x for x in range(10))
<generator object <genexpr> at 0xb7c1ccd4>
>>> list(_)
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
Ruby:
p = proc { |x| x * x }
(0..9).map(&p)
Python Python
>>> {x:str(y*y) for x,y in {1:2, 3:4}.items()}
{1: '4', 3: '16'}
Ruby:
>> Hash[{1=>2, 3=>4}.map{|x,y| [x,(y*y).to_s]}]
=> {1=>"4", 3=>"16"}
Python有装饰器
在Ruby中也可以创建类似于装饰器的东西，也可以认为它们不像在Python中那样必要。
语法差异
Ruby需要“end”或“}”来关闭所有作用域，而Python只使用空白。Ruby中最近已经尝试允许只使用空格缩进http://github.com/michaeledgar/seamless
Alex Martelli在comp.lang.python邮件列表中关于“Ruby比Python有什么更好”的回答。
Aug 18 2003, 10:50 am Erik Max Francis
wrote:
"Brandon J. Van Every" wrote:
What's better about Ruby than Python? I'm sure there's something.
What is it?
Wouldn't it make much more sense to ask Ruby people this, rather than
Python people?
Might, or might not, depending on
one's purposes -- for example, if
one's purposes include a "sociological
study" of the Python community, then
putting questions to that community is
likely to prove more revealing of
information about it, than putting
them elsewhere:-).
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 (e.g.,
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, e.g., Jython vs Classic Python
being two implementations of the
Python language!):
Ruby's iterators and codeblocks vs Python's iterators and generators;
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!
I.e., 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
d-e-a-t-h 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, e.g.,
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...).
Alex
