Курс mail.ru «Системное программирование на Perl»

чего это народ валит толпами на питон (уже почти все там). Чтобы искренне любить перл нужно быть немножко поехавшим.

Уж простите, но ЯП не телка что бы его любить или не любить. Это что-то из разряда я люблю зеленый молоток, но не люблю красную бензопилу. Всему свое применение.

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

Никаких других причин кодить на перле сегодня нет.

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

А какие есть причины кодить на python? Зачем нужен этот вязкий клей для си++ кода, если для всякой бигдаты есть прекрасный язык R со всем его умным и не чванливым при этом сообществом, есть Julia, воплощающая самые современные концепции ЯП и весьма быстрая. А для остального - я вообще теряюсь в догадках, зачем этот мерзотного вида быдлоязык нужен. Вот вам не нравится перл (хотя сами на нём ни строчки не написали или написали дрянь какую-то), а мне пайтон не нравится. И что?

Никаких других причин кодить на перле сегодня нет.

Прошлой осенью я был вынужден изучить Перл, чтобы писать наколеночные скрипты для обработки YAML. 10-20 строк длиной. Под другие языки столь же простых в использовании библиотек не нашлось. Можешь предложить что-то получше? Можно здесь что-нибудь оптимизировать?

Уж простите, но ЯП не телка что бы его любить или не любить. Это что-то из разряда я люблю зеленый молоток, но не люблю красную бензопилу. Всему свое применение.

А телку зачем любить? Всему свое применение.

Я твой тред не читал, но видел что ты там сравниваешь текст с переменной по умолчанию. Это не очень хорошая идея, но если уж дошло дело, то лучше делать:

/foo/

$_ eq 'foo'

Ну вот тот же скрипт на питоне.

import sys
import yaml

stats = {
        'STR_PISTOLS': (20, 15, 100),
        'STR_BOWS': (20, 15, 100),
        'STR_SMGS': (20, 15, 100),
        'STR_SHOTGUNS': (50, 40, 100),
        'STR_RIFLES': (50, 40, 100),
        'STR_SNIPER_RIFLES': (50, 40, 100),
        'STR_CANNONS': (65, 50, 100),
        'STR_MACHINE_GUNS': (65, 50, 100),
        'STR_LAUNCHERS': (80, 80, 100),
        }

res = {'items': []}

for item in yaml.load(open(sys.argv[1]))['items']:
    if 'categories' not in item or not set(item['categories']).intersection(stats.keys()) or 'STR_CLIPS' in item['categories']:
        continue
    new_item = {'type': item['type']}
    for k, v in stats.items():
        if k in item['categories']:
            new_item['meleePower'], new_item['tuMelee'], new_item['accuracyMelee'] = v
            break
    res['items'].append(new_item)

yaml.dump(res, open('out.rul', 'w'), default_flow_style=False)

Жесть какая:

    if 'categories' not in item or not set(item['categories']).intersection(stats.keys()) or 'STR_CLIPS' in item['categories']:
        continue

А это условие if строкой покороче записать никак нельзя? В смысле, разбиения на строки в python не завезли?

Можно, завезли.

'categories' not in item

Кстати, интересный пример.

С таким же успехом в perl хватает

if exists $item{'categories'}

Но в соотв. с логикой (считаем, что ключ, которому сопоставлено значение undef или 0 нас весьма мало интересует), можно просто вот так:

if $item{'categories'}

Вот только дальше по тексту в python уже считается, что item['categories'] - это список/вектор, а ведь это же может быть и не так. Почему вы не проверяете, не приехал ли к вам в данных от внешнего источника какая-либо невозбранная фигня, дальнейшая работа с которой в лучшем случае приведёт к исключению в рантайме?

В питоне обращение к несуществующему ключу бросит исключение. Но можно делать items.get('categories', дефолтное_значение) это довольно часто используется, например, делаешь пустой список дефолтным значением и можешь с ним смело работать как со списком.

Ещё есть defaultdict, в котором дефолтное значение задается при инициализации словаря т.е. можно делать что-то типа

In [1]: from collections import defaultdict

In [2]: d = defaultdict(list)

In [3]: d['foo'].append('a')

In [4]: d
Out[4]: defaultdict(list, {'foo': ['a']})

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

Потому что это наколенный скрипт под вполне конкертные данные.

В Пайтон нельзя что проверить тип значения, лежащего в items['categories']?

type(items['categories'])

Лучше isinstance

Мда, в рубях было бы items['categorises'].typeХотя конечно не факт, что так лучше.

есть items['categorises'].__class__

обычно в этом нет смысла. duck typing же. к тому же тип может быть создан динамически, или вообще мемберы могут быть напиханы снаружи. забавная история была с is_callable, когда его сначала выкинули, а потом опять вернули после некоторого срача. обычно рекомендуется проверять на trueness или если доставать мемберы через getattr.

Вообще это интересный вопрос. Ты будешь такие проверки всюду делать? И что делать, если в categories там что-то другое? Игнорировать как-то неправильно. Ругаться, падать? Ну тут и так эксепшн будет. Который залогируется, может даже прилетит на почту уведобление об этом с трейсбеком. И дальше надо разбираться, почему тебе данные пришли не в том формате, в каком ожидалось. И нормально ли это, если да, то надо как-то это учитывать в коде, конечно.

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

Даже в typing есть Callable, можно там даже задать типы аргументов и return type сразу.

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

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

Ну я обмазываю всё тайп хинтами. Но это не распростаняется на входные данные и работает не в рантайме(хотя есть https://github.com/RussBaz/enforce но это скорее для тестов).

Валидация внешних данных обязательна всегда, кроме разве что тех случаев, когда «очень некогда», а внешние данные являются таковыми лишь условно (для них не требуется защита от дурака или слишком умного). Причём здесь утиная типизация - я не в курсе.

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

Я валидирую данные, которые приходят от пользователя. А то, что возвращают сторонние api - нет. Будет исключение, я его залогирую, а пользователю вернется ошибка.

Это очень современный питон. Он хоть и идёт по дефолту много где, но часто только второй, особенно в энтерпрайзных el и centos. Поэтому для задач типа обсуждаемых в топике (заавтоматизировать что-то по мелочи) губу надо подзакатать. Хотя и с одной только базовой библиотекой можно много что сделать.

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

Задача была другая: приходит объект в функцию, если он callable, то надо работать с результатом его вызова, иначе с самим объектом. Например bound attribute vs bound method. Отсутствие рантпйм типизации иногда порождает извращённые решения: например, если функция может принимать iterable, но для удобства может принимать и один аргумент. Вот тогда делается что-то типа next(val), и в обработчике исключения создаётся одноэлементный список.

Мне кажется это всё неправильно. Функции не должны жрать что попало.

обычные - нет, а для метапрограммирования бывают нужны traits. Конкретно callable мне нужен был для реализации remote proxy, когда локальный вызов через перехват __get_attribute__ прозрачно сериализовался, вызвался удаленно, а результат возвращался. Хотя наверное можно было бы и декораторами проблему решить.

Спасибо, попробую.

Хотя Перл посоветовали авторы YAML :)