Ruby 2.0.0 preview1

Кто то не осилил функциональщину ;) и считает что программа которая не может сделать ничего полезного нужна.

у рельс по аналогии со stupid method, всё на столько очевидно что документация почти не нужна.

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

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

в документации отражено это особенность поведения, но она действительно не логичная

>в документации отражено

Ссылку?

Можно ссылку на документацию?

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

http://www.ruby-doc.org/core-1.9.3/String.html#method-i-split http://www.ruby-doc.org/core-1.9.3/String.html#method-i-slice описания нет но в примерах ниже

Пардонте есть описание

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

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

a,

(a,)

>>> list((i for i in range(3)))
[0, 1, 2]
>>> list(i for i in range(3))
[0, 1, 2]
>>> 

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

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

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

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

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

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

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

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

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

Ага...

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

Спомощью моего однострочника - тоже. Разница в том, что литералы будут обрабатываться встроенным 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))?

Будто у джанго нет таких проблем

В документации написано «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))?

да.

Ясно, спасибо. Это хорошо.

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

>>> 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,))

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

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

str = newt

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

newt < str

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

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

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

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

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

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

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

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

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

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

a = 1 + (1)

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

from numpy import empty

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

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

str = newt

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

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

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

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

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

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

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

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

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

class a:
    pass
b = lambda self, x: x*x
a.f = b
c = a()
print (c.f (5))

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

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

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

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

class a(object)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

fixed ;)

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

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

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

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

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

В Ruby  — Object.method { block }

В Clojure — (fun & args)

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

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