LINUX.ORG.RU

Ruby 2.0.0 preview1

 


2

6

Анонсирован Ruby 2.0.0 preview1. Были включены новые фишки, которые делают разработку на Ruby ещё приятнее.

Анонсированные фичи:

  • Уточнения (Refinements) [1]
  • Именованные аргументы в методах (сахар над хэшем) [2]
  • Enumerator#lazy [3]
  • Module#prepend [4]
  • #to_h
  • %i, для массивов символов
  • Движок регулярных выражений изменён на Onigmo [5]
  • Поддержка DTrace [6] (не включено)

Пока что ещё не все новые фишки включены в Ruby, это откладывается на следующие анонсы.

Не забываем устанавливать и находить баги, это только сделает Ruby лучше.

Все программы, которые написаны на ruby-1.9 будут работать на ruby 2.0, если в них не будет особой магии.

>>> Подробности

anonymous

Проверено: tazhate ()
Последнее исправление: tazhate (всего исправлений: 2)

Ответ на: комментарий от anonymous

Напиши как баг в их редмайн, или что там у них. Если не пофиксят, то хоть узнаешь в чём причина.

Deleted
()
Ответ на: комментарий от anonymous

На это есть тикет в их багтрекере? Если нет, кто может запостить баг? Интересно с чем связана такая особенность и почему ее не исправят?

anonymous
()
Ответ на: комментарий от Vudod

где есть разница между (a) и (a,)

Вообще-то по уму (а,) это частный случай (а). Так как

a,
это кортеж, содержащий один итем, а
(a,)
это уже обособление выражения, состоящего из кортежа. Скобки вообще не обязательны _синтаксически_ при определении кортежа. Они не входят в его синтаксис попросту. А если понимать, что (а) в Python это, как я написал, обособление выражения, то станет понятно, например, откуда растут уши у таких вещей, как отказ от лишней пары скобок при передаче генераторного выражения в функции, принимающие итераторы или последовательности. Например,
>>> list((i for i in range(3)))
[0, 1, 2]
>>> list(i for i in range(3))
[0, 1, 2]
>>> 
Посмотрели и сказали: а зачем, собственно, указывать лишнюю пару скобок, если и так есть скобки вызова функции, которые уже визуально выделяют выражение? Это, конечно, сахар, но, имхо, из разряда «pythonic».

Virtuos86 ★★★★★
()
Ответ на: комментарий от paranormal

казалось бы при чём тут java... видимо ты smalltalk никогда не видел.

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

А еще вы, видимо, не знаете историю ни смоллтока, ни жабы.

buddhist ★★★★★
()
Ответ на: комментарий от paranormal

У рельс откровенно говоря документация на тройку. И у рельс без сторонних gem'ов очень скудный функционал. Этот функционал насквозь пропитан conventions over configurations. Так как документация у рельс скудная то эти conventions over configurations полностью известны только авторам фреймворка, да и то наверное не всем.

Но доки рельс намного лучше чем доки gem'ов, количеством которых так кичатся рельсовики. Так как в рельсах толком ничего нет, то в проекте прийдется использовать over 9000 плохо документированных джемов. И когда эти джемы глючат или не хотят интегрироваться друг с другом то начинается жёсткий секас. Приходится лезть в исходники gem'ов что бы понять как это б**** работает. Но не тут то было. В исходниках адский ад, дсл, метапрограминг, conventions over configurations и манки патчинг.

Усугубляет это все скорость выполнения тестов и время старта рельс. Spork придумали не от хорошей жизни. Есть еще Zeus но он очень часто падает.

И напившись после очередного переноса запуска, ты будешь думать стоили ли рельсы всего этого...

anonymous
()
Ответ на: комментарий от Alve

Отмотаем машину времени на несколько лет назад и внезапно:

...внезапно не обнаружим Руби вообще.

Ага...

Что «ага»? Время жить и время умирать.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Спомощью моего однострочника - тоже. Разница в том, что литералы будут обрабатываться встроенным str.

Нет. Похоже, здесь мы не совсем друг друга понимаем.

Можно сценарий, в котором нужен monkeypatching именно встроенного типа? Потому что всё остальное и у меня патчится.

Не совсем так — нужно, чтобы отпатченный объект назывался везде одинаково. То есть это не должно быть классом c другим именем как у вас(newt < str). Встроенный это тип или нет — вторично.

Использовать можно для DCI, например — http://mikepackdev.com/blog_posts/35-dci-with-ruby-refinements

Нет.

В документации написано «the bases tuple itemizes the base classes and becomes the __bases__ attribute» http://docs.python.org/3.3/library/functions.html?highlight=type#type

Означает ли это, что можно сделать X = type('X', (MyOwnNotStandartTypeCoolObject,), dict(a=1))?

Anatolik ★★
()
Ответ на: комментарий от Anatolik

В документации написано «the bases tuple itemizes the base classes and becomes the __bases__ attribute» http://docs.python.org/3.3/library/functions.html?highlight=type#type

Имеется в виду, что base classes будут базовыми классами для нового класса. Поэтому,

Означает ли это, что можно сделать X = type('X',MyOwnNotStandartTypeCoolObject,), dict(a=1))?

да.

anonymous
()
Ответ на: комментарий от Virtuos86

Оно всё в теории хорошо. А на практике получаются дурацкие вопросы. Например, можно:

>>> a = 1 + (1)
Но никак нельзя:
>>> a = 1 + (1,)

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    a = 1 + (1,)
TypeError: unsupported operand type(s) for +: 'int' and 'tuple'
Можно сколько угодно рассказывать после этого при частные случаи. При этом можно:
>>> from numpy import empty
>>> x = empty(10)
>>> y = empty((10,))
И будет вам одно и то же. Приходится студентам раз за разом это объяснять. Потому что эти дурацкие скобки слишком многозначны. Хорошо, что в Питоне, особенно в 3, таких проблем немного.

Vudod ★★★★★
()
Ответ на: комментарий от Anatolik

нужно, чтобы отпатченный объект назывался везде одинаково. То есть это не должно быть классом c другим именем как у вас.

Что не так с обычным:

str = newt

Я не стал повторяться, потому что считал это очевидным. Вернись и прочитай мой первый пример.

newt < str

И чему это мешает?

Встроенный это тип или нет — вторично.

Не вижу, чем мое решение не хуже, чем refine, для случая невстроенного типа (у которого нет литералов).

Означает ли это, что можно сделать X = type('X', (MyOwnNotStandartTypeCoolObject,), dict(a=1))?

В Python 3 - да. В Python 2 для oldstyle-классов нужна другая магия, но она тоже есть.

tailgunner ★★★★★
()
Ответ на: комментарий от Vudod

И будет вам одно и то же

Это особенности функционирования empty, а не Python.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

У джанго документация лучше, больше функционала, джанго быстрее стартует. Не знаю как в джанго, но в python в целом меньше магии.

Рельсовики кричат на каждом углу что нашли серебряную пулю, а руби сказка. Или будьте добры соответствуйте или rails is overrated.

anonymous
()
Ответ на: комментарий от paranormal

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

val-amart ★★★★★
()
Ответ на: комментарий от Vudod

a = 1 + (1)

Если у вас такая практика... Хотя если имеется в виду обучение, то... мне все равно не понятно, что за тупые студенты. Вот реально, это не проблема, такую простую вещь уяснить. Если человек визуально не может распарсить, что он складывает коров с баранами, то либо он сам баран, либо не понимает, что пишет. А если он не понимает, то либо он опять обратно баран, либо ему плохо или нет так втолковали.

from numpy import empty

Проблемы разумности API прикладных библиотек к языку _никак_ не относятся. Там, может, для удобства так сделали, но это же не значит, что (10,) равнозначно 10! За пример незачёт :).

Virtuos86 ★★★★★
()
Ответ на: комментарий от tailgunner

Человеку надо просто объяснить, что Питон по-другому устроен. Что его функции это не руби-методы, object не Object, и патчить встроенные типы тут никто не позволит, максимум - наследовать от них. Правда, никто и не переживает от отсутствия такой архифичи :).

Virtuos86 ★★★★★
()
Ответ на: комментарий от tailgunner

str = newt

О, а вот это забавно. Что произойдет? newt перезапишет str глобально или только в рамках какого-нибудь контекста?

В Ruby это очевидная ошибка(если только мы сами не перепишем метод = для String, конечно).

Anatolik ★★
()
Ответ на: комментарий от Virtuos86

патчить встроенные типы тут никто не позволит

Ну, он-то хочет в осноном невстроенные :) Другое дело, что это тоже дурь и поэтому в Питоне не принято.

tailgunner ★★★★★
()
Ответ на: комментарий от Anatolik

newt перезапишет str глобально или только в рамках какого-нибудь контекста?

В рамках, естественно. Поэтому я и говорю о литералах - в случае литерала создание объекта производится без явного вызова конструктора.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ну, он-то хочет в осноном невстроенные :) Другое дело, что это тоже дурь и поэтому в Питоне не принято.

Конечно. Все, что не принято в Питоне — дурь.

Anatolik ★★
()
Ответ на: комментарий от Anatolik

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

class a:
    pass
b = lambda self, x: x*x
a.f = b
c = a()
print (c.f (5))
val-amart ★★★★★
()
Последнее исправление: val-amart (всего исправлений: 1)
Ответ на: комментарий от Anatolik

Все, что не принято в Питоне — дурь.

Купи себе немного логики. Всё, что дурь - не принято в Питоне (но часто возможно - просто на всякий случай).

tailgunner ★★★★★
()
Ответ на: комментарий от val-amart

то, что показал tailgunner нужно только для встроенных типов

Для любых. То, что показал я - это то, что происходило бы под капотом твоего кода, если бы ты написал

class a(object)
tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от yanka

беда Ruby в его синтаксисе, он «неочевиден»

Неочевиден язык, основная цель цель которого «принцип минимального удивления»? Да вы о каком-то другом Ruby говорите )

Alve ★★★★★
()
Ответ на: комментарий от Virtuos86

за пол-минуты успел напиться - ох, ловкач ;)

Пятнецо и руби vs python срач на лоре - просто праздник какой-то :)

Alve ★★★★★
()
Ответ на: комментарий от tailgunner

извини если не точно выразился. я просто хотел показать что для не встроенных типов это можно делать проще и короче.

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

У меня на строчку короче и работает как для встроенных, так и для невстроенных типов :) Но они должны быть newstyle.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

В рамках, естественно.

Тогда это очень неплохо. В самом деле.

Купи себе немного логики. Всё, что дурь - не принято в Питоне (но часто возможно - просто на всякий случай).

В Python'е очень много сомнительных решений и ограничений. Например, эти ваши функции. Все это делает Python очень сложным языком в сравнении с Ruby и Lisp'aми. Поэтому я бы не стал его идеализировать.

Anatolik ★★
()
Ответ на: комментарий от Alve

«принцип минимального удивления» говоришь?

irb(main):001:0> if false
irb(main):002:1>   var = 1
irb(main):003:1> end
nil
irb(main):004:0> var
nil
irb(main):005:0> bla
NameError: undefined local variable or method `bla' for main:Object
	from (irb):5
	from /home/victor/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'

а теперь питон

In [1]: if False:
   ...:     var = 1
   ...:     
   ...:     

In [2]: var
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/victor/<ipython console> in <module>()

NameError: name 'var' is not defined

In [3]: bla
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/victor/<ipython console> in <module>()

NameError: name 'bla' is not defined

Так что не надо про «принцип минимального удивления». Хотя в питоне тоже боков хватает. Но мне питоновские бока как-то более понятны. Руби же делался инопланетянами для инопланетян...

anonymous
()
Ответ на: комментарий от Anatolik

Например, эти ваши функции.

Угу а блоки, проки и лямбды делают руби простым и понятным. В питоне хотя бы нет лишних сущностей.

anonymous
()
Ответ на: комментарий от Anatolik

В Python'е очень много сомнительных решений и ограничений. Например, эти ваши функции. Все это делает Python очень сложным языком в сравнении с Ruby и Lisp'aми.

WAT? Что может быть проще функции? И функции прозрачно преобразуются в методы, объект становится первым аргументом.

P.S. CL - гораздо более сложный язык, чем Python, или ты о Lisp 1.5?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Угу а блоки, проки и лямбды делают руби простым и понятным.

Так и запишем, при чтении учебника до главы о проках и лямдах не дошёл. Впоследствии прочитал на лоре, что они «нинужны» и являются лишними сущностями.

Непонятными программы делают кривые руки программистов, перед которым все языки равны )

Alve ★★★★★
()
Ответ на: комментарий от tailgunner

WAT? Что может быть проще функции? И функции прозрачно преобразуются в методы, объект становится первым аргументом.

Как-то для меня вовсе не прозрачно. Вот объясни, зачем создавать лишнюю сущность — функции, если можно обойтись методами?

P.S. CL - гораздо более сложный язык, чем Python, или ты о Lisp 1.5?

CL — Lisp-2. Я про правильные простые Lisp'ы — Scheme, Clojure.

Anatolik ★★
()
Ответ на: комментарий от anonymous

Угу а блоки, проки и лямбды делают руби простым и понятным.

Да. Так и есть. И я писал в начале треда, почему это так-- Ruby 2.0.0 preview1 (комментарий)

В питоне хотя бы нет лишних сущностей.

Хорошая шутка.

Anatolik ★★
()
Ответ на: комментарий от st4l1k

Не в вебе у руби 3.5 проекта. Переписать все и оставить только морду, что это если не побег с рельс?

anonymous
()
Ответ на: комментарий от Anatolik

зачем создавать лишнюю сущность — функции, если можно обойтись методами?

Методы - частный случай функций.

Я про правильные простые Lisp'ы — Scheme, Clojure.

Clojure - простой Lisp? O_o

tailgunner ★★★★★
()
Ответ на: Ruby vs Python от yanka

Мой пост ничего не изменит.

fixed ;)

special-k ★★★★
()
Ответ на: комментарий от Anatolik

И в чем шутка? Если из ruby выкинуть все лишнее, добавить list comprehension и нормальный import (а не require уровня php) то получится python.

anonymous
()
Ответ на: комментарий от tailgunner

Методы - частный случай функций.

Или наоборот.

Clojure - простой Lisp? O_o

Ну да, очень высокая предсказуемость как у Ruby, так и у Clojure. Всегда один и тот же паттерн:

В Ruby  — Object.method { block }

В Clojure — (fun & args)

Anatolik ★★
()
Ответ на: комментарий от val-amart

Разница между этими ссылками - то что одна на страницу загрузки а вторая на документацию...

Когда я изучал GNU smalltalk - там документации было действительно мало. Ничего, выкручивался. Людям которые жалуются на скудную документацию по rails мне сказать нечего.

paranormal ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.