То, что Ruby имеет тем Python, не делает, и наоборот?

Surprised to see nothing mentioned of ruby's "method missing" mechanism. I'd give examples of the find_by_... methods in Rails, as an example of the power of that language feature. My guess is that something similar could be implemented in Python, but to my knowledge it isn't there natively.

Ruby имеет сигилы и twigils, Python - нет.

Edit : И одну очень важную вещь, которую я забыл (в конце концов, предыдущее было просто немного подразнить :-p):

Python имеет JIT-компилятор ( Psyco ), язык более низкого уровня для написания более быстрого кода ( Pyrex ) и возможность добавлять встроенный код C ++ ( Weave ).

У Python менталитет «мы все здесь взрослые». Таким образом, вы обнаружите, что в Ruby есть такие вещи, как константы, а в Python - нет (хотя константы Ruby вызывают только предупреждение). Образ мышления Python состоит в том, что если вы хотите сделать что-то постоянным, вы должны заключить имена переменных в заглавные буквы и не изменять их.

Например, Ruby:

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

Python:

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

Пример 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 не являются объектами первого класса. Функции должны быть заключены в объект, чтобы передавать их; результирующий объект нельзя рассматривать как функцию. Функции могут ' t быть назначенным первоклассным образом; вместо этого для их изменения должна быть вызвана функция в его объекте-контейнере.

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 имеет построчный цикл по входным файлам (флаг '-n') из командной строки, поэтому его можно использовать как AWK. Этот однострочник Ruby:

ruby -ne 'END {puts $.}'

будет подсчитывать такие строки, как однострочник AWK:

awk 'END{print NR}'

Ruby получает эту функцию через Perl, который взял его из AWK как способ привлечь системных администраторов к Perl без необходимости менять способ они что-то делают.

Что Ruby имеет по сравнению с Python, так это возможности языка сценариев. Язык сценариев в этом контексте означает, что он будет использоваться для «связующего кода» в сценариях оболочки и общих манипуляций с текстом.

В основном они используются в Perl. Первоклассные встроенные регулярные выражения, $ -переменные, полезные параметры командной строки, такие как Perl (-a, -e) и т. Д.

Вместе с его кратким, но выразительным синтаксисом он идеально подходит для такого рода задач.

Для меня Python - это скорее бизнес-язык с динамической типизацией, который очень легко выучить и имеет аккуратный синтаксис. Не такой "крутой", как Руби, но изящный. Что Python имеет для меня, так это огромное количество привязок для других библиотек. Привязки к Qt и другим библиотекам графического интерфейса, многим библиотекам поддержки игр и и и. У Руби намного меньше. Хотя часто используемые привязки, например, к базам данных, имеют хорошее качество, я обнаружил, что нишевые библиотеки лучше поддерживаются в Python, даже если для той же библиотеки есть привязка Ruby.

Итак, я бы сказал, что оба языка имеют свое использование, и это - это задача, определяющая, какой из них использовать. Обеим достаточно легко научиться. Я использую их рядом. Ruby для написания сценариев и Python для автономных приложений.

Вы можете импортировать только определенные функции из модуля в Python. В Ruby вы импортируете весь список методов. Вы можете «не импортировать» их в Ruby, но дело не в этом.

EDIT:

возьмем этот модуль Ruby:

module Whatever
  def method1
  end

  def method2
  end
end

, если вы включите его в свой код:

include Whatever

вы увидите, что оба method1 и method2 были добавлены в ваше пространство имен. Невозможно импортировать только method1 . Вы либо импортируете их оба, либо не импортируете вообще. В Python вы можете импортировать только те методы, которые вам нравятся. Если бы у него было имя, может быть, его назвали бы выборочным импортом?

Некоторые другие от:

http: //www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/

(Если я что-то исказил или что-то из них изменилось на стороне Ruby с эта страница была обновлена, кто-то может редактировать ...)

Строки изменяемы в Ruby, а не в Python (где новые строки создаются "изменениями").

Ruby имеет некоторые принудительные соглашения о регистрах, Python делает нет.

Python имеет как списки, так и кортежи (неизменяемые списки). Ruby имеет массивы, соответствующие спискам Python, но не имеет их неизменяемых вариантов.

В Python вы можете напрямую обращаться к атрибутам объектов. В Ruby это всегда через методы.

В Ruby круглые скобки для вызовов методов обычно необязательны, но не в Python.

Ruby имеет открытый, закрытый и защищенный доступ для принудительного доступа, вместо соглашения Python об использовании подчеркивания и искажение имени.

Python имеет множественное наследование. В Ruby есть «миксины».

И еще одна очень важная ссылка:

http://c2.com/cgi/wiki?PythonVsRuby

Которая, в частности, ссылается на еще одну хорошую ссылку от Alex Martelli , который также публиковал много замечательных материалов здесь, на SO:

http://groups.google.com/group/comp.lang.python/msg/028422d707512283

I ' m не уверен в этом, поэтому я сначала добавляю его в качестве ответа.

Python обрабатывает несвязанные методы как функции

Это означает, что вы можете вызывать метод типа theobject.themethod () или ] TheClass.themethod (anobject) .

Изменить: хотя разница между методами и функциями в Python невелика и не существует в Python 3, она также не существует в Ruby просто потому, что Ruby не ' t имеют функции. Когда вы определяете функции, вы фактически определяете методы для объекта.

Но вы все равно не можете взять метод одного класса и вызвать его как функцию, вам придется повторно привязать его к объекту, который вы хотите вызвать,

Ruby имеет встроенную поддержку продолжения с использованием callcc .

Следовательно, вы можете реализовать такие классные вещи, как amb-operator

«Переменные, начинающиеся с заглавной буквы, становятся константами и не могут быть изменены»

Неверно. Могут.

Вы получите предупреждение, только если сделаете это.

Python имеет явный встроенный синтаксис для составления списков и генераторов, тогда как в Ruby вы должны использовать карты и блоки кода.

Сравните

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

с

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

Я не думаю, что «Ruby имеет X, а Python - нет, в то время как Python имеет Y, а Ruby - нет» - это самый удобный способ взглянуть на это. Это очень похожие языки со многими общими способностями.

В значительной степени разница в том, что язык делает изящным и читаемым. Если использовать приведенный вами пример, оба теоретически имеют лямбда-выражения, но программисты Python склонны избегать их, а конструкции, созданные с их помощью, не выглядят столь же удобочитаемыми или идиоматическими, как в Ruby. Итак, в Python

Я хотел бы упомянуть API дескриптора Python, который позволяет настраивать "связь" объекта с атрибутом. Также примечательно, что в Python можно свободно реализовать альтернативный протокол, переопределив значение по умолчанию, заданное посредством реализации по умолчанию метода __ getattribute __ . Разрешите подробнее рассказать об этом. Дескрипторы - это обычные классы с методами __ get __ , __ set __ и / или __ delete __ . Когда интерпретатор встречает что-то вроде anObj.anAttr , выполняется следующее:

• __ getattribute __ вызывается метод anObj
• __ getattribute __ извлекает объект anAttr class dict
• проверяет, имеет ли объект abAttr __ get __ , __ set __ или __ delete __ вызываемые объекты
• контекст (то есть вызывающий объект или класс, и value, вместо последнего, если у нас есть сеттер) передается вызываемому объекту
• , результат возвращается.

Как уже упоминалось, это поведение по умолчанию. Можно изменить протокол, повторно реализовав __ getattribute __ .

Этот метод намного мощнее декораторов.

Python назвал необязательные аргументы

def func(a, b=2, c=3):
    print a, b, c

>>> func(1)
1 2 3
>>> func(1, c=4)
1 2 4

AFAIK Ruby имеет только позиционированные аргументы, потому что b = 2 в объявлении функции - это аффект, который всегда добавляется.

My python's rusty, so some of these may be in python and i just don't remember/never learned in the first place, but here are the first few that I thought of:

Whitespace

Ruby handles whitespace completely different. For starters, you don't need to indent anything (which means it doesn't matter if you use 4 spaces or 1 tab). It also does smart line continuation, so the following is valid:

def foo(bar,
        cow)

Basically, if you end with an operator, it figures out what is going on.

Mixins

Ruby has mixins which can extend instances instead of full classes:

module Humor
  def tickle
    "hee, hee!"
  end
end
a = "Grouchy"
a.extend Humor
a.tickle    »   "hee, hee!"

Enums

I'm not sure if this is the same as generators, but as of Ruby 1.9 ruby as enums, so

>> enum = (1..4).to_enum
=> #<Enumerator:0x1344a8>

Reference: http://blog.nuclearsquid.com/writings/ruby-1-9-what-s-new-what-s-changed

"Keyword Arguments"

Both of the items listed there are supported in Ruby, although you can't skip default values like that. Вы можете идти по порядку

def foo(a, b=2, c=3)
  puts "#{a}, #{b}, #{c}"
end
foo(1,3)   >> 1, 3, 3
foo(1,c=5) >> 1, 5, 3
c          >> 5

. Обратите внимание, что c = 5 фактически присваивает переменной c в вызывающей области значение 5 и устанавливает для параметра b значение 5.

, либо вы можете сделать это с помощью хешей, которые обращаются к второй выпуск

def foo(a, others)
  others[:b] = 2 unless others.include?(:b)
  others[:c] = 3 unless others.include?(:c)
  puts "#{a}, #{others[:b]}, #{others[:c]}"
end
foo(1,:b=>3) >> 1, 3, 3
foo(1,:c=>5) >> 1, 2, 5

Ссылка: Руководство прагматического программиста по Ruby

Ruby имеет встроенную документацию:

 =begin

 You could use rdoc to generate man pages from this documentation

 =end

Я хотел бы предложить вариант исходного вопроса: «Что есть в Ruby, чего нет в Python, и наоборот?» который допускает неутешительный ответ: «Что вы можете сделать с Ruby или Python, чего нельзя сделать в Intercal?» Ничего подобного, потому что Python и Ruby являются частью огромной королевской семьи, сидящей на троне приближенного Тьюринга.

Но как насчет этого:

Что можно сделать изящно и хорошо в Python, чего нельзя быть сделано на Ruby с такой красотой и хорошей инженерией, или наоборот?

Это может быть намного интереснее, чем простое сравнение функций.

С сайта Ruby :

Сходства Как и в случае с Python, в Ruby ...

• Есть интерактивная подсказка (называемая irb).
• Вы можете читать документацию в командной строке (с помощью команды ri вместо pydoc).
• Нет никаких специальных терминаторы строки (кроме обычного символа новой строки).
• Строковые литералы могут охватывать несколько строк, как строки Python с тройными кавычками.
• Скобки предназначены для списков, а фигурные скобки - для словарных скобок (которые в Ruby называются «хешами») .
• Массивы работают одинаково (добавление их создает один длинный массив, но их составление таким образом a3 = [a1, a2] дает вам массив массивов).
• Объекты сильно и динамично типизированный.
• Все является объектом, а переменные - просто ссылками на объекты.
• Хотя ключевые слова немного отличаются, исключения работают примерно так же.
• У вас есть встроенные инструменты документации (Ruby называется rdoc ).

Различия В отличие от Python, в Ruby ...

• Строки изменяемы.
• Вы можете создавать константы (переменные, значение которых вы не собираетесь изменять).
• Существуют некоторые принудительные соглашения о регистре (например, class имена начинаются с заглавной буквы, переменные начинаются со строчной буквы).
• Существует только один вид контейнера списка (массив), и он изменяемый.
• Строки в двойных кавычках допускают escape-последовательности (например, \ t) и специальный синтаксис «подстановки выражений» (который позволяет вставлять результаты выражений Ruby непосредственно в другие строки без необходимости «складывать» + «строки» + «вместе»). Строки в одинарных кавычках подобны «необработанным строкам» Python.
• Не существует классов «нового стиля» и «старого стиля». Только один вид.
• Вы никогда не имеете прямого доступа к атрибутам. В Ruby все вызовы методов.
• Круглые скобки для вызовов методов обычно необязательны.
• Есть открытый, закрытый и защищенный для принудительного доступа вместо Python _volvention_ подчеркивание __convention __ .
• «миксины» используются вместо множественного наследования .
• Вы можете добавлять или изменять методы встроенных классов. Оба языка позволяют открывать и изменять классы в любой момент, но Python предотвращает модификацию встроенных модулей - Ruby - нет.
• У вас есть true и false вместо True и False (и nil вместо None).
• 12128] При проверке на истинность только false и nil дают ложное значение. Все остальное верно (включая 0, 0.0, "" и []).
• Это elsif вместо elif.
• Требуется вместо импорта. Однако в остальном использование такое же.
• Обычные комментарии в строке (строках) над объектами (вместо строк документов под ними) используются для создания документов.
• Существует ряд горячих клавиш, которые, хотя и дают вам больше информации, чтобы помнить, вы быстро узнаете . Они, как правило, делают Ruby увлекательным и очень продуктивным.

Немного подробнее об инфраструктуре:

• Python намного лучше интегрируется с C ++ (через такие вещи, как Boost.Python , SIP и Py ++ ), чем Ruby, где параметры, похоже, либо записываются напрямую в API интерпретатора Ruby (что вы, конечно, можете делать и с Python, но в обоих случаях это низкоуровнево, утомительно, и подвержены ошибкам) ​​или используйте SWIG (хотя он работает и определенно хорош, если вы хотите поддерживать множество языков, но далеко не так хорош, как Boost.Python или SIP, если вы специально хотите привязать C ++).

• Python имеет несколько сред веб-приложений (Django, Pylons / Turbogears, web.py, вероятно, по крайней мере, полдюжины других), тогда как Ruby (по сути) имеет одну: Rails. (Существуют и другие веб-фреймворки Ruby, но, похоже, ему трудно добиться успеха в борьбе с Rails). Хорош это или плохо? Трудно сказать и, вероятно, довольно субъективно; Я легко могу представить аргументы в пользу того, что ситуация с Python лучше, а с Ruby - лучше.

• В культурном отношении сообщества Python и Ruby кажутся несколько разными, но я могу только намекнуть на это, поскольку у меня нет такого большого опыта взаимодействия с сообществом Ruby. Я добавляю это в основном в надежде, что кто-то, имеющий большой опыт работы с обоими способами, сможет усилить (или отклонить) это утверждение.

Другая разница в лямбдах между Python и Ruby продемонстрирована проблемой Пола Грэхэма Accumulator Generator. Переписано здесь:

Напишите функцию foo, которая принимает число n и возвращает функцию, которая принимает число i, и возвращает n, увеличенное на i. Замечание: (a) это число, а не целое, (b) которое увеличивается на, а не на плюс.

В Ruby это можно сделать:

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

На Python вы создадите объект, который будет держать состояние n:

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

Некоторые люди могут предпочесть явный подход на Python, как более ясный концептуально, даже если он немного более многословен. Вы храните состояние так же, как и для всего остального. Нужно просто обернуть голову вокруг пальца мыслью о вызываемых предметах. Но независимо от того, какой подход предпочитает эстетичный, он демонстрирует одно уважение, в котором Ruby lambdas являются более мощными конструкциями, чем Python's.

http://c2.com/cgi/wiki?pythonvsruby
http://c2.com/cgi/wiki?switchedfrompythontoruby
http://c2.com/cgi/wiki?switchedfromRubytopython
http://c2.com/cgi/wiki?usingPythondontneedRuby
http://c2.com/cgi/wiki?usingrubydontneedpython

_{Бесстыдно скопировано / вставлено из: Alex Martelli ответ на « Что лучше в Ruby, чем Python » ветка из comp.lang.python список рассылки.}

18 августа 2003 г., 10:50 Эрик Макс Фрэнсис писал:

«Брэндон Дж. Ван Эвери» писал:

Что лучше в Ruby, чем Python? Я уверен, что в этом что-то есть. Что это такое?

Разве не было бы лучше спросить об этом у Ruby людей, чем Люди Python?

Могут, а могут и нет, в зависимости от свои цели - например, если чьи-то цели включают "социологический исследование "сообщества Python, затем задавать вопросы этому сообществу - это может оказаться более разоблачительным информацию об этом, чем ставить их в другом месте :-).

Лично я с удовольствием взял возможность следовать за Дэйвом Томасом ' однодневный учебник по Ruby на последнем OSCON. Под тонким слоем синтаксиса различия, я нахожу Ruby и Python удивительно похоже - если бы я был вычисление минимального остовного дерева среди практически любого набора языков, Я почти уверен, что Python и Ruby быть первыми двумя листьями, чтобы слиться в промежуточный узел :-).

Конечно, в Ruby я устаю от набрав глупый "конец" в конце каждый блок (а не просто без отступа) - но тогда я доберусь до не набирайте столь же глупое ":" который Python требует в начало каждого блока, так что это почти промывка :-). Другой синтаксис различия, такие как "@foo" по сравнению с 'self.foo' или большее значение случая в Ruby vs Python, действительно почти не имеет для меня никакого отношения.

Другие, без сомнения, основывают свой выбор языки программирования именно на таких проблемы, и они генерируют самые горячие дебаты - но для меня это просто пример одного из законов Паркинсона в действие (сумма на дебаты по выпуск обратно пропорционален актуальная важность вопроса).

Изменить (от 19.06.2010, 11:45): это также известно как «рисование велогонка "(или, для краткости, "байкшеддинг") - ссылка есть, снова к Норткоуту Паркинсону, который дали "споры о том, в какой цвет красить велоспорт »как типичный пример «горячие дискуссии на банальные темы». (конец редактирования).

Одно различие в синтаксисе, которое я нашел важно, и в пользу Python - но другие люди без сомнения подумают как раз наоборот - это "как ты вызвать функцию, которая не принимает параметры ". В Python (как и в C) для вызова функции, которую вы всегда применяете «оператор вызова» - трейлинг круглые скобки сразу после объекта вы звоните (внутри этих висящих круглые скобки идут к аргументам, которые вы передаете в звонке - если вы проходите нет args, то круглые скобки пусты). Остается простое упоминание о любой объект без задействованного оператора, означающий просто ссылку объекту - в любом контексте, без особых случаев, исключений, специальные правила и тому подобное. В Ruby (как в Паскале), чтобы вызвать функцию С аргументами вы передаете аргументы (обычно в скобках, хотя не всегда так) - НО если функция не принимает аргументов, тогда просто неявное упоминание функции называет это.Это может встретить ожидания многих людей (по крайней мере, несомненно, те, у кого только предыдущие опыт программирования был с Паскаль или другие языки с аналогичный «неявный вызов», например Visual Basic), но для меня это означает простое упоминание объекта может ЛИБО означают ссылку на объект, ИЛИ вызов объекта, в зависимости от тип объекта - а в тех случаи, когда я не могу получить ссылку на объект, просто упомянув о нем я нужно будет использовать явное выражение "дайте мне ссылка на это, НЕ НАЗЫВАЙТЕ! " операторы, которые не нужны иначе. Я чувствую, что это влияет на «первоклассность» функций (или методы или другие вызываемые объекты) и возможность замены объекты плавно. Поэтому мне эта конкретная разница в синтаксисе серьезная черная метка против Руби - но Я понимаю, почему другие думают в противном случае, хотя я едва мог категорически не согласен с ними :-).

Ниже синтаксиса мы попадаем в некоторые важные отличия в элементарных семантика - например, строки в Ruby - это изменяемые объекты (например, в C ++), а в Python - нет. изменчивый (как в Java, или я верю C #). Опять люди, которые судят в первую очередь тем, что они уже знаком с может подумать, что это плюс для Ruby (если они не знакомы с Конечно, Java или C # :-).Я думаю неизменяемые строки - отличный идея (и я не удивлен, что Java, независимо, я думаю, заново изобрел это идея, которая уже была в Python), хотя я бы не прочь иметь также тип "изменяемый строковый буфер" (и в идеале с лучшим простота использования, чем собственная строка Java буферы "); и я не даю это суждение по фамильярности - до изучения Java, кроме функциональные языки программирования, где все данные неизменяемы,все языки, которые я знал, имели изменяемые строки - но когда я впервые увидел идею неизменяемой строки в Java (которую я выучил хорошо до того, как изучил Python), это сразу показалось мне отличным, очень хорошо подходит для эталонная семантика более высокого уровня язык программирования (в отличие от семантика значений, которая лучше всего соответствует языки ближе к машине и подальше от приложений, например C) со струнами в качестве первоклассного, встроенные (и довольно важные) данные тип.

У Ruby есть некоторые преимущества в элементарная семантика - например, удаление списков Python vs кортежи "чрезвычайно тонкие различие. Но в основном счет (как Держу, простота большой плюс и тонкие, умные различия заметный минус) против Ruby (например, как закрытые, так и полуоткрытые интервалы, с обозначениями a..b и a ... b [кто-нибудь хочет утверждать, что это очевидно что есть что? -)], это глупо - ИМХО конечно!). Опять таки, люди, которые считают, что у них много похожие, но немного разные вещи в ядро языка плюс, скорее чем МИНУС, конечно, будет засчитан эти "наоборот" от того, как Я их считаю :-).

Пусть вас не обманут эти сравнения. думать, что эти два языка очень разные, заметьте. Это не так.Но если меня попросят сравнить от "капелли д'Анджело" до "спагеттини", указав, что эти двое виды макарон примерно неотличимы от кого-либо и взаимозаменяемы в любом блюде хочу подготовиться, я бы тогда неизбежно придется переехать в микроскопическое исследование того, как длины и диаметры незаметно различаются, как концы прядей сужаются в одном корпусе, а не в другое и так далее - чтобы попытаться объяснить почему я лично предпочел бы капелли д'Анджело, как паста в любом вид бульона, но предпочел бы спагеттини как пастаскиутта на вынос с подходящими соусами так долго тонкие макаронные формы (оливковое масло, измельченные чеснок, рубленый красный перец и мелко например, молотые анчоусы - но если вы нарезали чеснок и перец вместо того, чтобы измельчать их, тогда вы следует выбрать более прочный корпус из спагетти, а не тоньше мимолетность спагеттини, и посоветуйте отказаться от ахов и добавить вместо этого немного свежей весны базилик [или даже - я еретик ...! - светлая мята ...] листья - у самого последний момент перед подачей блюда). Ой, извини, это показывает, что я ехал за границу и не ел пасты на какое-то время, я думаю. Но аналогия все еще довольно хорошо! -)

Итак, вернемся к Python и Ruby, мы подошли к двум крупным игрокам (с точки зрения собственно язык - оставив библиотеки и другие важные вспомогательное оборудование, такое как инструменты и среды, как встроить / расширить каждую язык и т. д., пока исключите его - они не будут применяться ко всем РЕАЛИЗАЦИЯМ каждого языка в любом случае, например, Jython против классического Python являясь двумя реализациями Язык Python!):

1. Итераторы и кодовые блоки Ruby против итераторов и генераторов Python;

2. ИТОГО Ruby, безудержная «динамичность», включая возможности
   чтобы "повторно открыть" любой существующий класс, включая все встроенные, и изменить его поведение во время выполнения - vs Python огромен, но ограничен динамичность, которая никогда не меняет поведение существующих встроенных классы и их экземпляры.

Лично я считаю 1 стиркой ( различия настолько глубоки, что я мог легко увидеть людей, ненавидящих подходить и уважать другого, но на МОИХ личных весах плюсы и минусы примерно равны); и 2 а ключевой вопрос - тот, который делает Ruby гораздо больше подходит для "мастеринга", НО Python одинаково больше подходит для использование в крупных производственных приложениях. В каком-то смысле это забавно, потому что оба языки намного более динамичны чем большинство других, что в конце концов ключевое отличие между ними от моего POV должен зависеть от того, что Руби "идет к одиннадцати" в этом отношении ( здесь ссылка на "Spinal Tap", из курс). В Ruby нет ограничений к моему творчеству - если я решу, что все сравнения строк должны стать без учета регистра, Я МОГУ ЭТО ! То есть я могу динамически изменять встроенный строковый класс, чтобы a = "Привет, мир" b = "привет, мир" если a == b напечатать "равно! \ n" еще напечатать "другое! \ n" конец БУДЕТ печатать «равно». В python я не могу этого сделать.В целях метапрограммирования внедрение экспериментальных фреймворков, и тому подобное, эта удивительная динамика способность Руби чрезвычайно привлекательный. НО - если мы говорим о больших приложениях, разработанных много людей и поддерживается даже больше, включая всевозможные библиотеки из разных источников и нуждаются в перейти в производство на сайтах клиентов ... ну, я не ХОЧУ языка, который Довольно динамично, большое спасибо.Я ненавижу саму идею какой-нибудь библиотеки невольно нарушая другие не связанные те, которые полагаются на то, что эти строки разные - вот такие глубокие и глубоко скрытый «канал», между фрагменты кода, которые ВЫГЛЯДЯТ отдельными и ДОЛЖЕН БЫТЬ отдельным, это означает d-e-a-t-h в крупномасштабном программировании. Позволяя любому модулю влиять на поведение любого другого «тайного» способность изменять семантику встроенные типы - это просто ПЛОХАЯ идея для программирование производственных приложений, просто как это круто повозиться.

Если бы мне пришлось использовать Ruby для такого большого приложение, я бы постарался положиться на ограничения стиля кодирования, множество тесты (для повторного запуска всякий раз, когда НИЧЕГО изменения - даже то, что должно быть полностью несвязанные ...) и тому подобное, чтобы запретить использование этой языковой функции. Но НЕ имея функции в первое место даже лучше, по моему мнение - так же, как и сам Python быть еще лучшим языком для прикладное программирование, если количество встроенных модулей может быть «прибито» вниз ", поэтому я ЗНАЛ, что, например, len ("ciao") равно 4 (вместо того, чтобы иметь подсознательно беспокоиться о том, кто-то изменил привязку имени 'len' во встроенном модуле ...). Я очень надеюсь, что в конечном итоге Python сделает "прибить" его встроенные модули.

Но проблема второстепенная, так как встроенные функции перепривязки - это довольно устарела, а также является редкой практикой в Python. В Ruby мне кажется, что major - как и слишком мощный макро-средства других языков (например, Дилан) представляют похожие риски по моему собственному мнению (я очень надеюсь что Python никогда не получит такой мощный макросистема, независимо от привлекательности "позволяя людям определять свои собственные предметно-ориентированные маленькие языки встроены в сам язык "- это будет, IMHO, испортить замечательный Python полезность для приложения программирование, представив "привлекательная неприятность" для потенциальных ремесленник, который прячется в каждом сердце программиста ...).

Алекс

В Ruby, когда вы импортируете файл с требовать, все, что определено в этот файл окажется в вашем глобальном пространство имен.

С помощью 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 по-прежнему имеет лучшую поддержку юникода

В то время как функциональность в значительной степени такая же (особенно в смысле Тьюринга ), злонамеренные языки утверждают, что Ruby был создан для питонистов, которые не могли разделиться со стилем программирования Perlish.