¿Qué tiene Ruby que Python no tiene, y viceversa?

Hay muchas discusiones sobre Python vs Ruby, y todas las encuentro completamente inútiles, porque todas dan vueltas por qué la característica X es una mierda en el lenguaje Y, o eso afirma que el lenguaje Y no tiene X, aunque en realidad sí lo tiene. También sé exactamente por qué prefiero Python, pero eso también es subjetivo, y no ayudaría a nadie a elegir, ya que es posible que no tengan los mismos gustos en desarrollo que yo.

Por lo tanto, sería interesante enumerar las diferencias de manera objetiva. Así que no "las lambdas de Python apestan". En cambio, explique lo que las lambdas de Ruby pueden hacer que Python no puede hacer. Sin subjetividad. ¡El código de ejemplo es bueno!

No tenga varias diferencias en una respuesta, por favor. Y vote por los que sabe que son correctos, y por los que sabe que son incorrectos (o subjetivos). Además, las diferencias en la sintaxis no son interesantes. Sabemos que Python hace con sangría lo que Ruby hace con corchetes y extremos, y que @ se llama self en Python.

ACTUALIZACIÓN: Esta es ahora una wiki comunitaria, por lo que podemos agregar las grandes diferencias aquí.

Ruby tiene una referencia de clase en el cuerpo de la clase.

En Ruby tienes una referencia a la clase (self) que ya está en el cuerpo de la clase. En Python, no tiene una referencia a la clase hasta que finaliza la construcción de la clase.

Un ejemplo:

class Kaka
  puts self
end

self en este caso es la clase, y este código imprimirá "Kaka". No hay forma de imprimir el nombre de la clase o de otra manera acceder a la clase desde el cuerpo de definición de clase en Python (definiciones de método externas).

Todas las clases son mutables en Ruby.

Esto le permite desarrollar extensiones para las clases principales. Aquí hay un ejemplo de una extensión de rieles:

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

Python (imagina que no hubiera ''.startswithmétodo):

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

Puede usarlo en cualquier secuencia (no solo cadenas). Con el fin de utilizarlo debe importar que explícitamente por ejemplo, from some_module import starts_with.

Ruby tiene características de script similares a Perl

Ruby tiene expresiones regulares de primera clase, $ -variables, el bucle de entrada línea por línea awk / perl y otras características que lo hacen más adecuado para escribir pequeños scripts de shell que combinan archivos de texto o actúan como código de pegamento para otros programas.

Ruby tiene continuaciones de primera clase.

Gracias a la declaración callcc. En Python puede crear continuaciones mediante diversas técnicas, pero no hay soporte integrado en el lenguaje.

Ruby tiene bloques

Con la instrucción "do" puede crear una función anónima de varias líneas en Ruby, que se pasará como un argumento al método frente a do, y se llamará desde allí. En Python, en su lugar, haría esto ya sea pasando un método o con generadores.

Rubí:

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

Python (los bloques Ruby corresponden a diferentes construcciones en Python):

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

O

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

O

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

amethod(function)     # `function` is a callback

Curiosamente, la declaración de conveniencia en Ruby para llamar a un bloque se llama "rendimiento", que en Python creará un generador.

Rubí:

def themethod
    yield 5
end

themethod do |foo|
    puts foo
end

Pitón:

def themethod():
    yield 5

for foo in themethod():
    print foo

Aunque los principios son diferentes, el resultado es sorprendentemente similar.

Ruby admite la programación de estilo funcional (similar a una tubería) más fácilmente

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

Pitón:

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

Python tiene generadores integrados (que se usan como bloques Ruby, como se señaló anteriormente)

Python tiene soporte para generadores en el lenguaje. En Ruby 1.8 puede usar el módulo generador que usa las continuaciones para crear un generador a partir de un bloque. O bien, ¡podría usar un bloque / proc / lambda! Además, en Ruby 1.9 las fibras son, y se pueden usar como, generadores, y la clase Enumerator es un generador incorporado 4

docs.python.org tiene este ejemplo de generador:

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

Contraste esto con los ejemplos de bloques anteriores.

Python tiene un manejo flexible del espacio de nombres

En Ruby, cuando importa un archivo con require , todas las cosas definidas en ese archivo terminarán en su espacio de nombres global. Esto causa la contaminación del espacio de nombres. La solución a eso son los módulos Rubys. Pero si crea un espacio de nombres con un módulo, entonces debe usar ese espacio de nombres para acceder a las clases contenidas.

En Python, el archivo es un módulo y puede importar sus nombres contenidos from themodule import *, contaminando así el espacio de nombres si lo desea. Pero también puede importar nombres seleccionados con from themodule import aname, anothero simplemente puede import themoduley luego acceder a los nombres con themodule.aname. Si desea más niveles en su espacio de nombres, puede tener paquetes, que son directorios con módulos y un __init__.pyarchivo.

Python tiene docstrings

Las cadenas de documentos son cadenas que se adjuntan a módulos, funciones y métodos y pueden introspectarse en tiempo de ejecución. Esto ayuda a crear cosas como el comando de ayuda y la documentación automática.

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

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

Los equivalentes de Ruby son similares a los javadocs, y se encuentran sobre el método en lugar de dentro de él. Se pueden recuperar en tiempo de ejecución de los archivos mediante el uso del ejemplo del método # source_location 1.9 de 1.9

Python tiene herencia múltiple

Ruby no lo hace ("a propósito" - vea el sitio web de Ruby, vea aquí cómo se hace en Ruby ). Reutiliza el concepto de módulo como un tipo de clases abstractas.

Python tiene comprensiones de listas / dict

Pitón:

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

Rubí:

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

Pitón:

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

Rubí:

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'}

Rubí:

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

Python tiene decoradores

También se pueden crear cosas similares a los decoradores en Ruby, y también se puede argumentar que no son tan necesarios como en Python.

Diferencias de sintaxis

Ruby requiere "fin" o "}" para cerrar todos sus ámbitos, mientras que Python usa solo espacios en blanco. Ha habido intentos recientes en Ruby para permitir espacios en blanco solo sangría http://github.com/michaeledgar/seamless

Ruby tiene los conceptos de bloques , que son esencialmente azúcar sintáctico alrededor de una sección de código; son una forma de crear cierres y pasarlos a otro método que puede o no usar el bloque. Se puede invocar un bloque más adelante mediante una yielddeclaración.

Por ejemplo, una definición simple de un eachmétodo en Arraypodría ser algo como:

class Array
  def each
    for i in self  
      yield(i)     # If a block has been passed, control will be passed here.
    end  
  end  
end  

Entonces puedes invocar esto así:

# Add five to each element.
[1, 2, 3, 4].each{ |e| puts e + 5 }
> [6, 7, 8, 9]

Python tiene funciones / cierres / lambdas anónimos, pero no tiene bloques, ya que le falta algo del azúcar sintáctico útil. Sin embargo, hay al menos una forma de obtenerlo de manera ad-hoc. Ver, por ejemplo, aquí .

Ejemplo de Python

Las funciones son variables de primera clase en Python. Puede declarar una función, pasarla como un objeto y sobrescribirla:

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

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

Esta es una característica fundamental de los lenguajes de script modernos. JavaScript y Lua también hacen esto. Ruby no trata las funciones de esta manera; nombrar una función la llama.

Por supuesto, hay formas de hacer estas cosas en Ruby, pero no son operaciones de primera clase. Por ejemplo, puede ajustar una función con Proc.new para tratarla como una variable, pero ya no es una función; Es un objeto con un método de "llamada".

Las funciones de Ruby no son objetos de primera clase.

Las funciones de Ruby no son objetos de primera clase. Las funciones deben estar envueltas en un objeto para pasarlas; El objeto resultante no puede ser tratado como una función. Las funciones no se pueden asignar de manera de primera clase; en su lugar, se debe llamar a una función en su objeto contenedor para modificarlos.

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!"    

En última instancia, todas las respuestas serán subjetivas en algún nivel, y las respuestas publicadas hasta ahora prueban que no se puede señalar ninguna característica que no sea factible en el otro idioma de una manera igualmente agradable (si no similar) , ya que ambos idiomas son muy concisos y expresivos.

Me gusta la sintaxis de Python. Sin embargo, debes profundizar un poco más que la sintaxis para encontrar la verdadera belleza de Ruby. Hay belleza zenlike en la consistencia de Ruby. Si bien ningún ejemplo trivial puede explicar esto completamente, intentaré encontrar uno aquí solo para explicar lo que quiero decir.

Invierta las palabras en esta cadena:

sentence = "backwards is sentence This"

Cuando piense en cómo lo haría, haría lo siguiente:

1. Divide la oración en palabras
2. Invierte las palabras
3. Vuelva a unir las palabras en una cadena

En Ruby, harías esto:

sentence.split.reverse.join ' '

Exactamente como lo piensa, en la misma secuencia, una llamada de método tras otra.

En python, se vería más así:

" ".join(reversed(sentence.split()))

No es difícil de entender, pero no tiene el mismo flujo. El sujeto (oración) está enterrado en el medio. Las operaciones son una mezcla de funciones y métodos de objeto. Este es un ejemplo trivial, pero uno descubre muchos ejemplos diferentes cuando realmente trabaja y comprende Ruby, especialmente en tareas no triviales.

Python tiene una mentalidad de "todos somos adultos aquí". Por lo tanto, encontrará que Ruby tiene cosas como constantes, mientras que Python no (aunque las constantes de Ruby solo generan una advertencia). La forma de pensar de Python es que si quieres hacer algo constante, debes poner los nombres de las variables en mayúsculas y no cambiarlo.

Por ejemplo, Ruby:

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

Pitón:

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

Solo puede importar funciones específicas de un módulo en Python. En Ruby, importa la lista completa de métodos. Podrías "no importarlos" en Ruby, pero no se trata de eso.

EDITAR:

tomemos este módulo Ruby:

module Whatever
  def method1
  end

  def method2
  end
end

si lo incluye en su código:

include Whatever

verá que tanto el método1 como el método2 se han agregado a su espacio de nombres. No puede importar solo el método1 . Los importas a ambos o no los importas en absoluto. En Python puede importar solo los métodos que elija. Si esto tuviera un nombre, ¿tal vez se llamaría importación selectiva?

Desde el sitio web de Ruby :

Similitudes Como con Python, en Ruby, ...

• Hay un mensaje interactivo (llamado irb).
• Puede leer documentos en la línea de comandos (con el comando ri en lugar de pydoc).
• No hay terminadores de línea especiales (excepto la nueva línea habitual).
• Los literales de cadena pueden abarcar varias líneas como las cadenas de triple cita de Python.
• Los corchetes son para listas, y los corchetes son para dictados (que, en Ruby, se denominan "hashes").
• Las matrices funcionan igual (agregarlas forma una matriz larga, pero componerlas así a3 = [ a1, a2 ] le proporciona una matriz de matrices).
• Los objetos están fuertemente y dinámicamente tipados.
• Todo es un objeto, y las variables son solo referencias a objetos.
• Aunque las palabras clave son un poco diferentes, las excepciones funcionan más o menos igual.
• Tienes herramientas de documentación incrustadas (Ruby se llama rdoc).

Diferencias a diferencia de Python, en Ruby, ...

• Las cuerdas son mutables.
• Puede hacer constantes (variables cuyo valor no desea cambiar).
• Hay algunas convenciones de casos forzadas (por ejemplo, los nombres de clase comienzan con una letra mayúscula, las variables comienzan con una letra minúscula).
• Solo hay un tipo de contenedor de lista (una matriz), y es mutable.
• Las cadenas entre comillas dobles permiten secuencias de escape (como \ t) y una sintaxis especial de "sustitución de expresiones" (que le permite insertar los resultados de expresiones Ruby directamente en otras cadenas sin tener que "agregar" + "cadenas" + "juntas") . Las cadenas entre comillas simples son como las "cadenas crudas" de Python.
• No hay clases de "estilo nuevo" y "estilo antiguo". Solo un tipo.
• Nunca accedes directamente a los atributos. Con Ruby, todo son llamadas a métodos.
• Los paréntesis para las llamadas a métodos suelen ser opcionales.
• Hay acceso público, privado y protegido para imponer el acceso, en lugar de Python _voluntary_ underscore __convention__ .
• "Mixin" se utilizan en lugar de herencia múltiple.
• Puede agregar o modificar los métodos de las clases integradas. Ambos idiomas le permiten abrir y modificar clases en cualquier momento, pero Python evita la modificación de los elementos integrados, Ruby no.
• Tienes verdadero y falso en lugar de verdadero y falso (y nulo en lugar de ninguno).
• Cuando se prueba la verdad, solo falso y nulo evalúan a un valor falso. Todo lo demás es cierto (incluidos 0, 0.0, "" y []).
• Es elsif en lugar de elif.
• Se requiere en lugar de importar. De lo contrario, el uso es el mismo.
• Los comentarios de estilo habitual en la (s) línea (s) sobre las cosas (en lugar de las cadenas de documentos debajo de ellas) se utilizan para generar documentos.
• Hay varios atajos que, aunque te dan más para recordar, aprendes rápidamente. Tienden a hacer que Ruby sea divertido y muy productivo.

Lo que Ruby tiene sobre Python son sus capacidades de lenguaje de script. El lenguaje de secuencias de comandos en este contexto significa que se utilizará para el "código de pegamento" en los scripts de shell y la manipulación general de texto.

Estos se comparten principalmente con Perl. Expresiones regulares incorporadas de primera clase, $ -Variables, opciones útiles de línea de comandos como Perl (-a, -e) etc.

Junto con su sintaxis breve pero epxresiva, es perfecta para este tipo de tareas.

Python para mí es más un lenguaje de negocios de tipo dinámico que es muy fácil de aprender y tiene una sintaxis clara. No es tan "genial" como Ruby, pero ordenado. Lo que Python tiene sobre Ruby para mí es la gran cantidad de enlaces para otras bibliotecas. Enlaces a Qt y otras bibliotecas GUI, muchas bibliotecas de soporte de juegos y y y. Ruby tiene mucho menos. Si bien los enlaces muy utilizados, por ejemplo, a las bases de datos son de buena calidad, encontré que las bibliotecas de nicho son mejor compatibles con Python, incluso si para la misma biblioteca también hay un enlace Ruby.

Entonces, yo diría que ambos idiomas tienen su uso y es la tarea que define cuál usar. Ambos son lo suficientemente fáciles de aprender. Los uso uno al lado del otro. Ruby para scripting y Python para aplicaciones independientes.

No creo que "Ruby tenga X y Python no, mientras que Python tiene Y y Ruby no" es la forma más útil de verlo. Son lenguajes bastante similares, con muchas habilidades compartidas.

En gran medida, la diferencia es lo que el lenguaje hace elegante y legible. Para usar un ejemplo que mencionaste, ambos teóricamente tienen lambdas, pero los programadores de Python tienden a evitarlos, y las construcciones hechas con ellos no parecen tan legibles o idiomáticas como en Ruby. Entonces, en Python, un buen programador querrá tomar una ruta diferente para resolver el problema que lo haría en Ruby, solo porque en realidad es la mejor manera de hacerlo.

Me gustaría sugerir una variante de la pregunta original, "¿Qué tiene Ruby que Python no tiene y viceversa?" que admite la respuesta decepcionante: "Bueno, ¿qué puedes hacer con Ruby o Python que no se puede hacer en Intercal?" Nada en ese nivel, porque Python y Ruby son ambos parte de la vasta familia real sentada en el trono de ser aproximadamente Turing.

Pero qué hay de esto:

¿Qué se puede hacer con gracia y bien en Python que no se puede hacer en Ruby con tanta belleza y buena ingeniería, o viceversa?

Eso puede ser mucho más interesante que la mera comparación de características.

Python tiene una sintaxis incorporada explícita para comprensiones de listas y generadores, mientras que en Ruby usaría bloques de código y de mapa.

Comparar

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

a

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

"Las variables que comienzan con mayúscula se convierten en constantes y no se pueden modificar"

Incorrecto. Ellos pueden.

Solo recibes una advertencia si lo haces.

Algo más en el lado de la infraestructura:

• Python tiene una integración mucho mejor con C ++ (a través de cosas como Boost.Python , SIP y Py ++ ) que Ruby, donde las opciones parecen estar escritas directamente en la API de intérprete de Ruby (que también puede hacer con Python, por supuesto, pero en ambos casos, hacerlo es de bajo nivel, tedioso y propenso a errores) o usar SWIG (que, si bien funciona y definitivamente es excelente si desea admitir muchos idiomas, no es tan bueno como Boost.Python o SIP si específicamente está buscando vincular C ++).

• Python tiene varios entornos de aplicaciones web (Django, Pylons / Turbogears, web.py, probablemente al menos media docena de otros), mientras que Ruby (efectivamente) tiene uno: Rails. (Existen otros marcos web de Ruby, pero aparentemente tienen dificultades para obtener mucha tracción contra Rails). ¿Es este aspecto bueno o malo? Difícil de decir, y probablemente bastante subjetivo; Puedo imaginar fácilmente argumentos de que la situación de Python es mejor y que la situación de Ruby es mejor.

• Culturalmente, las comunidades Python y Ruby parecen algo diferentes, pero solo puedo insinuar esto, ya que no tengo mucha experiencia interactuando con la comunidad Ruby. Estoy agregando esto principalmente con la esperanza de que alguien que tenga mucha experiencia con ambos pueda amplificar (o rechazar) esta declaración.

_{Copió / pegó descaradamente de: Alex Martelli responde en el hilo " ¿Qué es mejor sobre Ruby que Python " de la lista de correo comp.lang.python .}

18 de agosto de 2003, 10:50 am Erik Max Francis escribió:

"Brandon J. Van Every" escribió:

¿Qué hay de mejor en Ruby que en Python? Estoy seguro de que hay algo. ¿Qué es?

¿No tendría mucho más sentido preguntarle a la gente de Ruby esto, en lugar de preguntarle a la gente de Python?

Podría, o no, dependiendo de los propósitos de uno; por ejemplo, si los propósitos de uno incluyen un "estudio sociológico" de la comunidad de Python, entonces hacer preguntas a esa comunidad probablemente resulte más revelador de información al respecto, que ponerlas en otro lugar :-).

Personalmente, aproveché la oportunidad para seguir el tutorial de un día de Dave Thomas sobre Ruby en el último OSCON. Debajo de una delgada capa de diferencias de sintaxis, encuentro que Ruby y Python son increíblemente similares: si calculara el árbol de expansión mínimo entre casi cualquier conjunto de idiomas, estoy bastante seguro de que Python y Ruby serían las dos primeras hojas en fusionarse un nodo intermedio :-).

Claro, me canso, en Ruby, de escribir el tonto "final" al final de cada bloque (en lugar de simplemente desangrar), pero luego evito escribir el igualmente tonto ':' que Python requiere en el comienzo de cada bloque, así que eso es casi un lavado :-). Otras diferencias de sintaxis como '@foo' versus 'self.foo', o la mayor importancia del caso en Ruby vs Python, son realmente tan irrelevantes para mí.

Otros, sin duda, basan su elección de lenguajes de programación en tales problemas, y generan los debates más candentes, pero para mí eso es solo un ejemplo de una de las Leyes de Parkinson en acción (la cantidad de debate sobre un tema es inversamente proporcional a la del tema importancia real).

Editar (antes de la AM 19/06/2010 11:45): esto también se conoce como "pintar el bikeshed" (o, para abreviar, "bikeshedding") - la referencia es, nuevamente, a Northcote Parkinson, quien dio "debates" sobre qué color pintar el bikeshed "como un ejemplo típico de" debates candentes sobre temas triviales ". (fin de edición).

Una diferencia de sintaxis que considero importante, y a favor de Python, pero otras personas sin duda pensarán exactamente lo contrario, es "cómo se llama a una función que no toma parámetros". En Python (como en C), para llamar a una función siempre se aplica el "operador de llamada" - paréntesis finales justo después del objeto que está llamando (dentro de esos paréntesis finales van los argumentos que está pasando en la llamada, si no estás pasando argumentos, entonces los paréntesis están vacíos). Esto deja la mera mención de cualquierobjeto, sin operador involucrado, ya que significa solo una referencia al objeto, en cualquier contexto, sin casos especiales, excepciones, reglas ad-hoc y similares. En Ruby (como en Pascal), para llamar a una función CON argumentos, pasa los argumentos (normalmente entre paréntesis, aunque ese no es siempre el caso) - PERO si la función no tiene argumentos, simplemente mencionar la función implícitamente la llama. Esto puede cumplir con las expectativas de muchas personas (al menos, sin duda, aquellas cuya única experiencia previa de programación fue con Pascal u otros lenguajes con "llamadas implícitas" similares, como Visual Basic), pero para mí, significa la mera mención de un objeto puede significar ya sea una referencia al objeto, O una llamada al objeto, dependiendo del tipo de objeto, y en los casos en que puedo ' Para obtener una referencia al objeto con solo mencionarlo, tendré que usar explícitamente "¡dame una referencia a esto, NO lo llames!" operadores que no son necesarios de otra manera. Siento que esto afecta la "primera clase" de funciones (o métodos u otros objetos invocables) y la posibilidad de intercambiar objetos sin problemas. Por lo tanto, para mí, esta diferencia de sintaxis específica es una marca negra seria contra Ruby, pero entiendo por qué los demás pensarían lo contrario, a pesar de que difícilmente podría estar en desacuerdo con ellos con más vehemencia :-). de funciones (o métodos u otros objetos invocables) y la posibilidad de intercambiar objetos sin problemas. Por lo tanto, para mí, esta diferencia de sintaxis específica es una marca negra seria contra Ruby, pero entiendo por qué los demás pensarían lo contrario, a pesar de que difícilmente podría estar en desacuerdo con ellos con más vehemencia :-). de funciones (o métodos u otros objetos invocables) y la posibilidad de intercambiar objetos sin problemas. Por lo tanto, para mí, esta diferencia de sintaxis específica es una marca negra seria contra Ruby, pero entiendo por qué los demás pensarían lo contrario, a pesar de que difícilmente podría estar en desacuerdo con ellos con más vehemencia :-).

Debajo de la sintaxis, llegamos a algunas diferencias importantes en la semántica elemental: por ejemplo, las cadenas en Ruby son objetos mutables (como en C ++), mientras que en Python no son mutables (como en Java, o creo que C #). Una vez más, las personas que juzgan principalmente por lo que ya están familiarizados pueden pensar que esto es una ventaja para Ruby (a menos que estén familiarizados con Java o C #, por supuesto :-). Yo, creo que las cadenas inmutables son una excelente idea (y no me sorprende que Java, independientemente, creo que reinventó esa idea que ya estaba en Python), aunque tampoco me importaría tener un tipo de "buffer de cadena mutable" (e idealmente uno con mejor facilidad de uso que los propios "buffers de cadenas" de Java); y no juzgo por familiaridad, antes de estudiar Java, todos los datos son inmutables, todos los lenguajes que conocía tenían cadenas mutables; sin embargo, cuando vi por primera vez la idea de la cadena inmutable en Java (que aprendí mucho antes de aprender Python), inmediatamente me pareció excelente, una muy buena opción para la semántica de referencia de un lenguaje de programación de nivel superior (a diferencia de la semántica de valor que mejor se adapta a los lenguajes más cercanos a la máquina y más alejados de las aplicaciones, como C) con cadenas como una primera clase, incorporada (y bonita crucial) tipo de datos.

Ruby tiene algunas ventajas en la semántica elemental, por ejemplo, la eliminación de la distinción extremadamente sutil de "listas vs tuplas" de Python. Pero sobre todo el puntaje (como lo mantengo, con simplicidad, una gran ventaja y distinciones sutiles e inteligentes, un notable menos) está en contra de Ruby (por ejemplo, tener intervalos cerrados y medio abiertos, con las anotaciones a..by a .. .b [alguien quiere decir que es obvio cuál es cuál? -)], es una tontería - ¡En mi humilde opinión, por supuesto!). Una vez más, las personas que consideran tener muchas cosas similares pero sutilmente diferentes en el núcleo de un idioma MÁS, en lugar de MENOS, por supuesto contarán esto "al revés" de la forma en que los cuento :-).

No se deje engañar por estas comparaciones para pensar que los dos idiomas son muydiferente, te importa. No lo son Pero si me piden que compare "capelli d'angelo" con "spaghettini", después de señalar que estos dos tipos de pasta son prácticamente indistinguibles para cualquiera e intercambiables en cualquier plato que desee preparar, entonces inevitablemente tendría para pasar al examen microscópico de cómo las longitudes y diámetros difieren imperceptiblemente, cómo se afilan los extremos de los hilos en un caso y no en el otro, y así sucesivamente, para tratar de explicar por qué yo personalmente preferiría capelli d 'angelo como la pasta en cualquier tipo de caldo, pero preferiría espaguetis como la pastasciutta para ir con salsas adecuadas para esas formas largas y delgadas de pasta (aceite de oliva, ajo picado, pimientos rojos picados y anchoas finamente molidas, por ejemplo, pero si rebanó los ajos y los pimientos en lugar de picarlos, entonces debe elegir el cuerpo de espagueti más sólido en lugar de la evanescencia más delgada de los espaguetis, y le recomendamos que renuncie a las achovies y agregue un poco de albahaca fresca de primavera [ o incluso, soy un hereje ...! - hojas de menta clara - en el último momento antes de servir el plato). Vaya, lo siento, eso demuestra que estoy viajando al extranjero y no he comido pasta por un tiempo, supongo. ¡Pero la analogía sigue siendo bastante buena! -) - hojas de menta clara - en el último momento antes de servir el plato). Vaya, lo siento, eso demuestra que estoy viajando al extranjero y no he comido pasta por un tiempo, supongo. ¡Pero la analogía sigue siendo bastante buena! -) - hojas de menta clara - en el último momento antes de servir el plato). Vaya, lo siento, eso demuestra que estoy viajando al extranjero y no he comido pasta por un tiempo, supongo. ¡Pero la analogía sigue siendo bastante buena! -)

Entonces, volviendo a Python y Ruby, llegamos a los dos grandes (en términos del lenguaje apropiado: abandonar las bibliotecas y otros elementos auxiliares importantes como herramientas y entornos, cómo incrustar / extender cada idioma, etc., etc.) por ahora, no se aplicarían a todas las IMPLEMENTACIONES de cada idioma de todos modos, por ejemplo, Jython vs Classic Python son dos implementaciones del lenguaje Python):

1. Los iteradores y bloques de código de Ruby frente a los iteradores y generadores de Python;

2. La "dinámica" desenfrenada TOTAL de Ruby, que incluye la capacidad
   de "reabrir" cualquier clase existente, incluidas todas las integradas, y cambiar su comportamiento en tiempo de ejecución, frente a la gran pero limitada dinámica de Python , que nunca cambia el comportamiento de las clases existentes. clases incorporadas y sus instancias.

Personalmente, considero que 1 es un lavado (las diferencias son tan profundas que fácilmente podría ver a las personas odiando cualquiera de los dos enfoques y revertir el otro, pero en MIS escalas personales, las ventajas y desventajas son casi iguales); y 2 un tema crucial, uno que hace que Ruby sea mucho más adecuado para "retoques", PERO Python es igualmente más adecuado para su uso en aplicaciones de gran producción. Es divertido, en cierto modo, porque ambos idiomas son MUCHO más dinámicos que la mayoría de los demás, que al final la diferencia clave entre ellos de mi POV debería depender de eso: que Ruby "va a once" en este sentido (la referencia aquí es "Spinal Tap", por supuesto). En rubí¡PUEDO HACER ESO ! Es decir, puedo alterar dinámicamente la clase de cadena incorporada para que a = "Hello World" b = "hello world" si a == b print "igual! \ N" sino print "different! \ N" end WILL print " igual". En python, NO hay forma de que pueda hacer eso. A los efectos de la metaprogramación, la implementación de marcos experimentales y similares, esta increíble capacidad dinámica de Ruby es extremadamente atractivo. PERO, si hablamos de aplicaciones grandes, desarrolladas por muchas personas y mantenidas por más, incluyendo todo tipo de bibliotecas de diversas fuentes, y que necesitan entrar en producción en sitios de clientes ... bueno, no QUIERO un lenguaje que es MUY dinámico, muchas gracias. Odio la idea de que una biblioteca rompa involuntariamente otras no relacionadas que confían en que esas cadenas son diferentes: ese es el tipo de "canal" profundo y profundamente oculto, entre piezas de código que MIRAN separadas y DEBEN SER separadas, que deletrean la muerte en programación a gran escala. Al permitir que cualquier módulo afecte el comportamiento de cualquier otro "encubierto", la capacidad de mutar la semántica de los tipos incorporados es solo una MALA idea para la programación de aplicaciones de producción,

Si tuviera que usar Ruby para una aplicación tan grande, trataría de confiar en restricciones de estilo de codificación, muchas pruebas (para volver a ejecutar cada vez que CUALQUIER COSA cambie, incluso lo que debería estar totalmente sin relación ...) y similares, para prohibir el uso de esta función de lenguaje. Pero NO tener la función en primer lugar es incluso mejor, en mi opinión, de la misma manera que Python sería un lenguaje aún mejor para la programación de aplicaciones si se pudiera "concretar" cierto número de funciones integradas, por lo que SABÍA que , por ejemplo, len ("ciao") es 4 (en lugar de tener que preocuparse subliminalmente de si alguien ha cambiado el enlace del nombre 'len' en el módulo integrado ...). Espero que eventualmente Python "clave" sus elementos integrados.

Pero el problema es menor, ya que volver a vincular los elementos integrados es una práctica bastante obsoleta y poco común en Python. En Ruby, me parece importante, al igual que las instalaciones macro demasiado potentes de otros idiomas (como, por ejemplo, Dylan) presentan riesgos similares en mi opinión (espero que Python nunca tenga un sistema macro tan poderoso, no importa el encanto de "dejar que las personas definan sus propios pequeños idiomas específicos de dominio incrustados en el lenguaje en sí mismo", en mi humilde opinión, perjudicaría la maravillosa utilidad de Python para la programación de aplicaciones, al presentar una "molestia atractiva" al aspirante a manipulador que acecha en el corazón de cada programador ...).

Alex

Algunos otros de:

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

(Si he malinterpretado algo o alguno de estos ha cambiado en el lado de Ruby desde que se actualizó esa página, alguien puede editarlo ...)

Las cadenas son mutables en Ruby, no en Python (donde las nuevas cadenas son creadas por "cambios").

Ruby tiene algunas convenciones de casos forzados, Python no.

Python tiene listas y tuplas (listas inmutables). Ruby tiene matrices correspondientes a las listas de Python, pero no hay una variante inmutable de ellas.

En Python, puede acceder directamente a los atributos del objeto. En Ruby, siempre es a través de métodos.

En Ruby, los paréntesis para las llamadas a métodos suelen ser opcionales, pero no en Python.

Ruby tiene acceso público, privado y protegido para forzar el acceso, en lugar de la convención de Python de utilizar guiones bajos y nombres de nombres.

Python tiene herencia múltiple. Ruby tiene "mixins".

Y otro enlace muy relevante:

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

Lo que, en particular, enlaza con otro bueno de Alex Martelli , quien también ha estado publicando muchas cosas geniales aquí en SO:

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

No estoy seguro de esto, así que primero lo agrego como respuesta.

Python trata los métodos independientes como funciones

Eso significa que puede llamar a un método como theobject.themethod()o por TheClass.themethod(anobject).

Editar: aunque la diferencia entre métodos y funciones es pequeña en Python y no existe en Python 3, tampoco existe en Ruby, simplemente porque Ruby no tiene funciones. Cuando define funciones, en realidad está definiendo métodos en Object.

Pero aún no puede tomar el método de una clase y llamarlo como una función, tendría que volver a vincularlo al objeto al que desea llamar, lo que es mucho más obstinado.

Me gustaría mencionar la API de descriptor de Python que permite personalizar la "comunicación" de objeto a atributo. También es digno de mención que, en Python, uno es libre de implementar un protocolo alternativo anulando el valor predeterminado dado a través de la implementación predeterminada del __getattribute__método. Permítanme dar más detalles sobre lo mencionado anteriormente. Los descriptores son clases regulares con __get__, __set__y / o __delete__métodos. Cuando el intérprete encuentra algo como esto anObj.anAttr, se realiza lo siguiente:

• __getattribute__anObjSe invoca el método de
• __getattribute__ recupera un objeto Attr de la clase dict
• Se comprueba si el objeto abAttr tiene __get__, __set__o __delete__los objetos no desembolsadas
• el contexto (es decir, el objeto o la clase que llama, y ​​el valor, en lugar de este último, si tenemos setter) se pasa al objeto invocable
• Se devuelve el resultado.

Como se mencionó, este es el comportamiento predeterminado. Uno es libre de cambiar el protocolo al volver a implementarlo __getattribute__.

Esta técnica es mucho más poderosa que los decoradores.

Ruby tiene soporte de continuación incorporado usando callcc.

Por lo tanto, puede implementar cosas interesantes como el operador amb

En esta etapa, Python todavía tiene un mejor soporte Unicode

Python tiene cadenas de documentos y Ruby no ... O si no las tiene, no son accesibles tan fácilmente como en Python.

PD. Si estoy equivocado, bonito por favor, ¿deja un ejemplo? Tengo una solución alternativa que podría incluir en las clases con bastante facilidad, pero me gustaría tener la función docstring de alguna manera "nativa".

Ruby tiene un bucle línea por línea sobre los archivos de entrada (el indicador '-n') desde la línea de comandos para que pueda usarse como AWK. Esta línea de rubí:

ruby -ne 'END {puts $.}'

contará líneas como el AWK one-liner:

awk 'END{print NR}'

Ruby obtiene esta función a través de Perl, que lo tomó de AWK como una forma de hacer que los administradores de sistemas se unan a Perl sin tener que cambiar la forma en que hacen las cosas.

Ruby tiene sigilos y ramitas, Python no.

Editar : Y una cosa muy importante que olvidé (después de todo, lo anterior fue solo para encender un poco :-p):

Python tiene un compilador JIT ( Psyco ), un lenguaje de nivel visualmente inferior para escribir código más rápido ( Pyrex ) y la capacidad de agregar código C ++ en línea ( Weave ).

Mi pitón está oxidado, por lo que algunos de estos pueden estar en python y simplemente no recuerdo / nunca aprendí en primer lugar, pero aquí están los primeros que pensé:

Espacio en blanco

Ruby maneja los espacios en blanco completamente diferentes. Para empezar, no necesita sangrar nada (lo que significa que no importa si usa 4 espacios o 1 pestaña). También realiza la continuación de línea inteligente, por lo que lo siguiente es válido:

def foo(bar,
        cow)

Básicamente, si termina con un operador, se da cuenta de lo que está sucediendo.

Mixins

Ruby tiene mixins que pueden extender instancias en lugar de clases completas:

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

Enumeraciones

No estoy seguro de si esto es lo mismo que los generadores, pero a partir de Ruby 1.9 ruby ​​como enumeraciones, entonces

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

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

"Argumentos de palabras clave"

Los dos elementos enumerados allí son compatibles con Ruby, aunque no puede omitir valores predeterminados como ese. Puedes ir en orden

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

Tenga en cuenta que c = 5 en realidad asigna a la variable c en el alcance de la llamada el valor 5 y establece el parámetro b en el valor 5.

o puede hacerlo con hashes, que abordan el segundo problema

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

Referencia: La guía del programador pragmático para Ruby

Puede tener código en la definición de clase en Ruby y Python. Sin embargo, en Ruby tienes una referencia a la clase (self). En Python no tiene una referencia a la clase, ya que la clase aún no está definida.

Un ejemplo:

class Kaka
  puts self
end

self en este caso es la clase, y este código imprimirá "Kaka". No hay forma de imprimir el nombre de la clase o de otra manera acceder a la clase desde el cuerpo de definición de clase en Python.

La sintaxis no es algo menor, tiene un impacto directo en cómo pensamos. También tiene un efecto directo sobre las reglas que creamos para los sistemas que utilizamos. Como ejemplo, tenemos el orden de las operaciones debido a la forma en que escribimos ecuaciones u oraciones matemáticas. La notación estándar para las matemáticas permite a las personas leerla de más de una manera y llegar a diferentes respuestas dada la misma ecuación. Si hubiéramos utilizado la notación de prefijo o postfijo, habríamos creado reglas para distinguir cuáles eran los números a manipular en lugar de tener solo reglas para el orden en que se calculan los valores.

La notación estándar deja en claro de qué números estamos hablando al tiempo que hace que el orden en el que se calculan sea ambiguo. La notación de prefijos y postfijos hace que el orden en el que se compute sea simple mientras que los números son ambiguos. Python ya tendría lambdas multilínea si no fuera por las dificultades causadas por el espacio en blanco sintáctico. (Existen propuestas para lograr este tipo de cosas sin agregar necesariamente delimitadores de bloque explícitos).

Me resulta más fácil escribir condiciones en las que quiero que ocurra algo si una condición es falsa, es mucho más fácil escribir con la declaración a menos en Ruby que la construcción semánticamente equivalente "si no" en Ruby u otros idiomas, por ejemplo. Si la mayoría de los idiomas que la gente usa hoy en día tienen el mismo poder, ¿cómo puede considerarse que la sintaxis de cada idioma es algo trivial? Después de características específicas como bloques y mecanismos de herencia, etc., la sintaxis es la parte más importante de un lenguaje, apenas algo superficial.

Lo superficial son las cualidades estéticas de la belleza que atribuimos a la sintaxis. La estética no tiene nada que ver con cómo funciona nuestra cognición, la sintaxis sí.

Sorprendido de no ver nada del mecanismo de "método perdido" de Ruby. Daría ejemplos de los métodos find_by _... en Rails, como un ejemplo del poder de esa característica del lenguaje. Supongo que algo similar podría implementarse en Python, pero que yo sepa no está allí de forma nativa.

El problema del generador de acumuladores de Paul Graham demuestra otra diferencia en lambdas entre Python y Ruby . Reimpreso aquí:

Escriba una función foo que tome un número n y devuelva una función que tome un número i, y devuelva n incrementada en i. Nota: (a) es un número, no un entero, (b) se incrementa en, no más.

En Ruby, puedes hacer esto:

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

En Python, crearía un objeto para mantener el estado de n:

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

Algunas personas podrían preferir el enfoque explícito de Python como más claro conceptualmente, incluso si es un poco más detallado. Almacena el estado como lo hace para cualquier otra cosa. Solo necesita comprender la idea de los objetos invocables. Pero independientemente de cuál enfoque prefiera estéticamente, muestra un respeto en el que las lambdas de Ruby son construcciones más poderosas que las de Python.

Python ha nombrado argumentos opcionales

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 solo ha posicionado argumentos porque b = 2 en la declaración de función es una afectación que siempre se agrega.

Ruby tiene documentación incrustada:

 =begin

 You could use rdoc to generate man pages from this documentation

 =end

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

En Ruby, cuando importa un archivo con require, todas las cosas definidas en ese archivo terminarán en su espacio de nombres global.

Con Cargo puede " requerir bibliotecas sin saturar su espacio de nombres ".

# 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 = importar ("foo-1.0.0")
>> Foo2 = importar ("foo-2.0.0")
>> Foo1 :: VERSIÓN
=> "1.0.0"
>> Foo2 :: VERSIÓN
=> "2.0.0"