Релиз Ruby 2.1

undef_method :to_s

А почему бы тогда не сделать сразу

class Array; undef_method :join; end

Если не указано обратное, то когда речь идет об Array — имеется в виду то, что крякает как Array, и когда речь идет о ruby-объекте — имеется в виду то, что крякает как Object. Поэтому будьте любезны в своих «пруфах», рассуждениях и поучениях не нарушать этих предпосылок.

Это было не про Py, а про логическую модель и возможности гетерогенного контейнера вообще.

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

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

применим для любого контейнера? Или, может быть, все-таки вы ведете речь о какой-то специальной «логической модели» для особых людей?

Потому что сигнатура указывает какие аргументы принимает ф-я и что возвращает назад.

К сожалению, в случае с Python — это не совсем так. В документации Python в сигнатурах не указывается возвращаемое значение. Например, функции с этими сигнатурами

str.join(iterable)
str.endswith(suffix[, start[, end]])
str.partition(sep)

Сказано, что принимает iterable и возвращает строку, так оно всегда и есть.

Ах, если бы. В том-то и дело, что не всегда. Вы же сами сейчас цитируете «A TypeError will be raised if there are any non-string values in iterable».

Если в сигнатуре указано, что передать нужно тип iterable, и при передаче iterable мы получаем TypeError — это неконсистентное поведение.

Следовательно что? Верно, в сигнатуре негде об этом сказать.

Нет, не верно. Чтобы иметь право на TypeError для некоторых iterable, там должно было бы быть что-то вроде stringable_iterable, но система типов в Python для этого недостаточно хороша.

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

Можно вопрос: можешь посмотреть все вызовы join, что ты когда-либо писал, и сказать, сколько из них «корректных», а в скольких ты был вынужден приводить элементы в строку? Если перевод в строку был не в самом join, а строкою или парой строк выше, то засчитывается во второй вариант. Если в обозримой окрестности join перевода в строку хотя бы одного элемента не было, то в «корректный».

Про join и TypeError. Возникновение исключения в исключительной ситуации - это недостаток? Хотя если умалчивание о исключениях в стиле php (например, озорные прогулки за границами списка) считать достоинством, то наверное да...

http://itcrowd.mynthon.net/wp-content/uploads/2009/03/python-vs-php-errors-hi...

В документации Python в сигнатурах не указывается возвращаемое значение.

По ссылке очень много слов «return», после которых исчерпывающе указывается возвращаемое значение. Также там указываются и входные параметры. Или под «сигнатурами» имеется в виду что-то еще?

Если в сигнатуре указано, что передать нужно тип iterable, и при передаче iterable мы получаем TypeError — это неконсистентное поведение.

iterable это не тип, а интерфейс (и этот интерфейс недвусмысленно специфицируется далее как строковый итератор; тут писали, что это, дескать, «приписка», но чьи проблемы, что кто-то не умеет читать документацию); все последующие рассуждения неверны, так как основываются на этой неверной предпосылке.

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

Если поменять местами ruby и Python, то смысл не поменяется, не так ли? И конкретно в этом треде в откровенном хамстве можно обвинить кого угодно, но не питонистов.

А почему бы тогда не сделать сразу <...> и жаловаться на то, что #join не работает? Ваш «пруф» подменяет понятия.

Зачем? Цель проиллюстрировать ошибочность аргумента «за» на счёт включения join() методом Array():

... Здесь Ruby заблаговременно избавляет вас от того, чтобы вызвать метод для типа данных, который его не поддерживает. Поэтому в Ruby сперва нужно конвертировать в Array

Оказалось, что это свойство гарантирует Object задавая дефолтный to_s, а не Array. Где здесь подмена понятий?

Поэтому будьте любезны в своих «пруфах», рассуждениях и поучениях не нарушать этих предпосылок.

Мб я где-то не прав в своих рассуждениях если в Rb существуют объекты унаследованные не от Object и у которых, соответственно, может не быть дефолтного to_s. Такое имеет место быть?

Вы уверены, что ваш тезис <...> применим для любого контейнера?

Для гетерогенного контейнера (~ строго не типизированный). Это, например, list() в py и Array в Rb. Но уже не std::list<...> в плюсах.

К сожалению, в случае с Python — это не совсем так. В документации Python в сигнатурах не указывается возвращаемое значение

Указываются, но мб не везде

S.join(iterable) -> str

Однако нужно иметь в виду, что это не сигнатура. В Ruby и Python в сигнатурах ф-ий нет типов, или они все ~object.

Ах, если бы. В том-то и дело, что не всегда. Вы же сами сейчас цитируете «A TypeError will be raised if there are any non-string values in iterable».

Всегда. Если выкинулось исключение, то значит до retrun выполнение программы не дошло, т.е. ещё ничего возвращено не было. Всегда возвращает ... не значит «не выкидывает исключений». Оба рассматриваемых ЯП могут кинуть исключение где угодно и в документации эти моменты оговариваются редко.

Нет, не верно. Чтобы иметь право на TypeError для некоторых iterable, там должно было бы быть что-то вроде stringable_iterable,

Это должно как-то быть оговренно в документации. И там это явно указано, сам же привёл цитату в своём ответе. Упоминание в «сигнатуре» это тоже в данном случае документация.

но система типов в Python для этого недостаточно хороша

Так и в Ruby тоже нет такого типа. Не нужно только снова писать про Array, который тоже не является типизированным.

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

Хамить ~ сказать что ты не знаешь Ruby? Но это же очень похоже на правду. Зачем рассуждаешь о недостатках в безусловной форме когда сам не разбираешься в деталях и придумываешь мнимые недостатки.

Если перевод в строку был не в самом join, а строкою или парой строк выше, то засчитывается во второй вариант.

С какого это хрена? Несколькими строками выше мог где-то внутри ошибиться и неправильно перевести в str. Например, часто делаю так

class TypeIFace(object):
    def __data__(s):
        raise Exception('not implemented')

    @staticmethod
    def plainfy(obj): return obj.__data__()

class Ext_N_Type(TypeIFace):
    def __data__(s):
        # do something
     
        return something

map(TypeIFace.plainfy, ordered)

1. проверка на наиличие реализованного __data__();

2. проверка на корректность возвращаемого типа из конвертора, т.е. __data__() -> str;

Можно вопрос: можешь посмотреть все вызовы join, что ты когда-либо писал, и сказать, сколько из них «корректных», а в скольких ты был вынужден приводить элементы в строку?

Итого, большая часть «корректных», второй вариант обычно использую только для какого-нибудь дебага

careers stackoverflow говорит о том что руби до жабы - как до марса пешком.
java - 323
ruby - 180
odesk и далее по списку такая же ситуация

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

На самом деле, это слишком много, я не думаю, что на свете есть столько рубистов:)) Кроме того, столь большое количество неповоротливого энтероптоза может замедлить развитие языка и библиотек.. надеюсь этого не будет.

энтероптоза

энтерпрайза ах-ах))

надеюсь этого не будет

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

Java проекты нечасто отдают на freelance. Но даже на freelance биржах java опережает ruby в ~3 раза (см. odesk). Если посмотреть на linkedin то там ситуация для ruby куда более печальная
java - 15 677
ruby - 3 315
За пределами стартаперской движухи руби и рельсы особо никому не нужны. Да и в пределах стартаперской движухи популярность рельс сильно упала потому что появились более хипстерские технологии. Найти работу рубисту в xSSR (не удаленку, не freelance) вообще практически нереально.

Это просто забавно, неужели у рубистов все настолько плохо?)

неужели у рубистов все настолько плохо?)

Что плохо-то, клоун?)) У руби все ахрененно по этим цифрам. Количество бабла вливаемое вендорами в яву, в миллионы раз больше бабла вливаемого в руби, а разница в спросе копеечная. Долго ли это продлится - вот вопрос:)

java - 15 677
ruby - 3 315

Ты думаешь жабаделов в 5 раз больше?) Их гораздо-гораздо больше:) А проектов только в 5.. пичаль(

Java проекты нечасто отдают на freelance.

Читаю: «яву никто не использует по доброй воле».

Плохо то что ты идиот. Спрос на java разрабов намного выше спроса на ruby разрабов, спорить с этим может только идиот. По соотношению кол. вакансий/кол. разрабов ruby опять сосет у java. Вот тебе пруф для неньки http://dou.ua/lenta/articles/djinni-kogo-hotyat-rabotodateli/ для остальных стран xSSR ситуация приблизительно такая же.

«Количество бабла вливаемое вендорами в яву» ушло в том числе и на JIT в Java. Руби же медленный как черепаха и вливать деньги в его ускорение никто не хочет. Руби как неуловимый Джо...

Читаю: «яву никто не использует по доброй воле».

Читаю: «special-k не понимает элементарных фактов ИТ индустрии. Как например того что ынтерпрайз (в силу очевидных причин) в большинстве случаев работает с аутсорс/аутстаф конторами, а не с фрилансерами»

спорить с этим может только идиот

На самом деле, дрочить на чей спрос выше может только неопытный сосунок. Меня полностью устраивает ситуация со спросом на руби.

Руби же медленный как черепаха и вливать деньги в его ускорение никто не хочет.

У-тю-тю, а ты всех-всех поспрашивал?)))

На самом деле, дрочить на чей спрос выше может только неопытный сосунок. Меня полностью устраивает ситуация со спросом на руби.

Вопрос не в том что устраивает тебя. А в том что если руби и рейлс такой апупенный (как говорят рубисты) то где вакансии? Вакансий толком нет, значит вся крутость рубей и рельс не более чем выдумки рубистов.

У-тю-тю, а ты всех-всех поспрашивал?)))

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

то где вакансии?

Тыщи их, ты сам писал, амнезия штоле..

ынтерпрайз

вещь унылая и непримечательная

Во всем мире тысячи, в Украине ~17. С таким раскладом на сало не заработаешь...

Долго ли это продлится - вот вопрос:)

А что кстати ява.. Оно же подыхающая в пользу html5 (как и флэш). Говорил бы уж js-js бла-бла-бла. Он и для рельс нужен так-то, клиент же надо на чем-то писать.

Чем очередной стартап лучше? В большинстве своем на старте это очень простые проекты на три с половиной формы.

А что кстати ява.. Оно же подыхающая в пользу html5

Каким боком html5 заменит яву на бекенде?

Прикольные вещи типа гитхаба, гугла, ютуба.. некогда стартапы, ага.

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

Каким боком html5 фрондендщики прийдут в разработку ынтырпрайз бекенда?

js присутствует и на бэкенде, если что, а все очень любят делать единую платформу.

фрондендщики

Не все так узко специализированны.

[sarcasm]Стартапов такого уровня ппц как много и все они конечно же аутсорсятся в страны восточной европы.[/sarcasm]
В большенстве случаев это очередной сервис для владельцев диких пчел или прочая никому не нужная херь...

Каким боком html5 фрондендщики прийдут в разработку ынтырпрайз

от отчаянья наверно, хз..

В большенстве случаев это очередной сервис для владельцев диких пчел или прочая никому не нужная херь...

А мне какое дело..

Если что html5 != js ты же писал

А что кстати ява.. Оно же подыхающая в пользу html5

js входит в html5. Все разработчики на html5 должны уметь писать на js.

Node.js не входит в html5. Шансы у ноды заменить яву нулевые.

Шансы у ноды заменить яву нулевые.

Смелое заявление ах-ах)

все очень любят делать единую платформу

Java нужна для того что бы можно было индусу отдать педалить ынтерпрайз код. С JS это не прокатит.

Ты какое-то гребанное скопище баек.

Ой кто бы говорил...

Расслабьтесь. PHP популярнее =).

Следи ввнимательнее, что пишешь и наследуешь.

Ты ведь графикой занимаешься, если мне память не изменяет? Не должен разработчик (почему не верстальщик?) на html5 знать js. Это отдельный язык разметки, прекрасно работающий сам по себе :)

Другое дело, что ввели data-* атрибуты, для которых нужен js, но необходимости в них по-прежнеу нет.

Здесь под html5 понимается стек технологий: html5, css3, js, webgl, websocket, canvas ... здесь не имелся ввиду сам язык разметки html, потому речь шла не о верстальщиках.

Все варианты кроме первого убоги.

третий хорош, сразу видно тип и количество переменных

факинг мэджик - это

"abc".join("def") => dabceabcf

сразу видно тип

и какой же он?

Неизвестно, но будет пытаться стать %s ;)

Дык и в остальных вариантах то же самое.

В остальных нет такой явности.

Есть, посмотри http://docs.python.org/2/library/string.html#formatspec

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

популярнее в чем? и что это дает?

вот вопросы которые должен задавать себе «прикладной» разработчик :)

В остальных нет такой явности.

Согласен. Чтобы повысить явность, необходимо ввести в Python что-то вроде

String "Hello, %(String s)" %  String name

Будет явнее, что при интерполяции в строку возвращается строка.