Плохой Питон

Что ж с тобой будет от знакомства с pattern matching'ом?..

Не понял твоей мысли. Совсем не понял. Ты считаешь, что словари достойная замена свитчу или же наоборот?

Я, если что, считаю что это говно, но уж что есть. Я предпочёл бы иметь switch.

Вроде достойно держался, а тут взял и лопнул

Я или питон? Никогда не любил третий. Сначала они всё сломали, потом починили, когда уже не нужно было, а затем ещё и напихали в язык чего не попадя.

я ещё всю ночь кодил. Видимо, придётся потом разгребать

лол )

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

Но питон старше явы, классов там изначально вообще не было. Потом появились old-style classes, в которых не было даже наследования. А в java не было лямбды никакой. Про исключения без комментариев.

Не понял твоей мысли. Совсем не понял.

Ты pattern matching видел? Вот, например, примеры из Растбука:

let x = 'c';

match x {
    'a' ... 'j' => println!("early ASCII letter"),
    'k' ... 'z' => println!("late ASCII letter"),
    _ => println!("something else"),
}

или

fn main() {
    let p = Point { x: 0, y: 7 };

    match p {
        Point { x, y: 0 } => println!("On the x axis at {}", x),
        Point { x: 0, y } => println!("On the y axis at {}", y),
        Point { x, y } => println!("On neither axis: ({}, {})", x, y),
    }
}

Я или питон?

Ты. Третий питон шикарен, второй давно пора добить.

В хаскеле видел, а в расте разве что мельком глаза, совсем на него не тянет (я честно пытался). Так чего сказать-то хотел?

второй давно пора добить

Во фрю 2.7 только-только официально завезли, а ты предлагаешь добить.

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

обработка ексепшенов
что любым другим объектно-ориентированным языком

все перемешалось в бедной твоей голове.

попробуй объяснить взаимосвязь обработки ексепшенов и объектной ориентированности? Для начала себе. Не пытайся сразу вываливать это сюда.

попробуй объяснить взаимосвязь обработки ексепшенов и объектной ориентированности?

Внезапно, в питоне исключения представлены в виде объектов. От них можно наследоваться, есть интроспекция, можно ловить по родителю и так далее. Концептуально связи нет, а вот конкретно в питоне ООП полностью определяет то, как ты будешь работать с исключениями.

Кстати об объектной ориентированности.

Когда в голове у разработчиков каша, то они пишут

string.join(iterable)
regexp.match(str)

Эти идиоты не совпадение в строке ищут, а строку к совпадению примеряют!

Эти тупицы не массив джойнят в строку через разделитель, а к разделителю применяют массив!

# пример пиздеца
'/'.join(['path', 'to', 'dir'])

Внезапно, в питоне исключения представлены в виде объектов

представленность исключений в виде объектов

1. не связывает механизм исключений с объектно-ориентированной парадигмой
2. является обычным идиотизмом питона: нахрена 100500 классов исключений, если 99.999% из них просто инкапсулируют в себе просто строку текста?

Концептуально связи нет
не связывает механизм исключений с объектно-ориентированной парадигмой

Зачем ты повторяешь то, с чем я согласен?

нахрена 100500 классов исключений, если 99.999% из них просто инкапсулируют в себе просто строку текста?

Смысл вообще не в строке текста. Как раз таки в 99.999% случаев текст никому и не всрался. И стектрейсов, кстати, в норме тоже никто не видит. Я тебе выше всё пояснил, вчитайся, там ничего особенно умного не сказано, даже тебе должно быть понятно.

Мне не нужен трейс после него, мне не нужен трейс до него. мне нужен ексепшен без трейса указывающий на вызвавшую строку!

«Мне не нужно исключение, мне нужно исключение!»

Что тебе мешает написать функцию, которая выведет информацию о втором фрейме и завершит процесс?

def croak(info = None):
    import sys
    import traceback
    s = traceback.extract_stack()[-3]
    print("{}:{}: {}".format(s[0], s[1], info))
    sys.exit(1)

def level2():
    print("at level 2")
    croak("Message")
    print("at level 2 (again)")

def level1():
    print("at level 1")
    level2()

level1()

А можно писать a(b(c(d(e(f(g))))) - так ещё читабельнее?

А ведь на перле можно тоже нормально писать... Но травмированные тащут это даже в питон.

Пофиксил:

s = traceback.extract_stack()
s = s[random.randint(0, len(s)-1)]

Так оно чуть больше удовлетворяет потребности персонажа.

Что тебе мешает написать функцию, которая выведет информацию о втором фрейме и завершит процесс?

то, что если это библиотека, то это некорректное поведение

то, что если это библиотека, то это некорректное поведение

Разве хвалёный тобой croak не аналог die?

когда я пишу враппер над вызовом пользователя, то я могу указать croak'у что ошибка здесь невозможна

А где она возможна? Два уровня назад или может быть три? Ты этого не знаешь.

А можно писать a(b(c(d(e(f(g))))) - так ещё читабельнее?

если вся программа к этому сводится, то вполне да.

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

Например парсим простейшую CSV в объекты и складываем в хеш юзеров:

# CSV: id;name;enabled
%users = map { ($_->[0], { id => $_->[0], name => $_->[1] }) }
           grep { $_->[2] }
              map {[split /;/, $_]} 
                split /\n/, $csv;

На выходе получаем красивый хеш неотключенных пользователей, который например можно сложить в БД:

{
   "1": { "id": "1", "name": "Вася" },
   "7": { "id": "7", "name": "Петя" }
}

Так что в функциональном программировании нет ничего плохого :)

А где она возможна? Два уровня назад или может быть три? Ты этого не знаешь

1. на текущем уровне она невозможна, поскольку пришла с параметрами
2. если предыдущие уровни являются врапперами, тупо передающими параметры далее по стеку, то предыдущие уровни вполне могут сообщить об этом и соответственно croak будет указывать именно на место ошибки

Перловик пытается учить остальных писать читаемый код. Теперь я видел всё.

Есть куча вариантов как сделать то что ты хочешь, просто открой гугл :). А в стандартной библиотеке или самом языке это иметь - фу-фу-фу.

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

• средства документирования (perldoc)
• развитые средства для тестирования, включенные в std (никакой pytest, unittest не стоял рядом с Test::More)
• удобные средства указать пользователю библиотеки на ЕГО ошибку (Carp/croak)

А так же Perl - это субкультура, где считается зазорным писать код без автоматических тестов, например

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

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

Например парсим простейшую CSV

дожили, в перле даже простейший парсер превращается в нечто нечитаемое.

зазорным писать код без автоматических тестов

собственно, а перл тут при чем ?

если предыдущие уровни являются врапперами, тупо передающими параметры далее по стеку, то предыдущие уровни вполне могут сообщить об этом и соответственно croak будет указывать именно на место ошибки

Как они могут это сообщить?

конвеер функций - типовое функциональное программирование

hint: bash-pipe

foo | bar | baz

hint: lisp итп

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

1. функции применяются однократно
2. функции применяются на месте объявления

собственно, а перл тут при чем ?

Perl - это субкультура, тесты и документирование кода - лежат в её базисе.

Как они могут это сообщить?

perldoc Carp

дожили, в перле даже простейший парсер превращается в нечто нечитаемое.

Что тебя смутило, расскажи. Или читаемое - это обязательно императивная портянка не менее сотни строк?

читаемое - это обязательно императивная портянка не менее сотни строк?

ага, у них 3 строки же не прочитаешь, не зачитаешься во вс. случае ;)

попробуй объяснить взаимосвязь обработки ексепшенов и объектной ориентированности?

Объясняю: во всех объектно-ориентированных языках существует обработка исключений. Доступное объяснение?

тесты и документирование кода - лежат в её базисе

Ничоси, теперь очевидные практики разработки - базис перла.

конвеер функций

ты мне по ошибке ответил ? При чем тут то что я написал. Я увидел твой код, его сложно читать, для того чтобы определить какую роль он выполняет нужно разобраться в стеке ф-ций, держать их в голове. С ходу даже нельзя понять в какой момент поступают данные, а заодно определить в чем суть этого $_

bash

я тебе намекну, в твоем примере есть целых 3 имени «ф-ций» foo,bar,baz

Ничоси, теперь очевидные практики разработки - базис перла.

в Python сделано всё чтобы затруднить тестирование.

посмотрите на pytest, это - ППЦ.

сведение тестов к падающему assert - до этого мог додуматься только тот, кто хотел чтобы тесты не писали, а уж если написали, то они были бы минимально информативны

ППЦ

ППЦ у тебя аргументы, просто ППЦ

с каких пор pytest обязателен ? Выбери для себя нужную, тысячи их

минимально информативны

для тех кто держит документацию в тестах есть нативный doctest

Perl - это субкультура, тесты и документирование кода - лежат в её базисе.

Твой парсер ломается, если поле содержит точку с запятой. И где твоя субкультура теперь?

switch должен быть либо OrderedDict иначе может случиться фейл. И dict здесь в принципе особо не нужен, можно списком обойтись.

Не нужен, просто дикт читаемей списка таплов.

Зачем тебе потоки? Числодробилки на нем писать собрался? Явно не тот инструмент.

А какие конкретные притензии к третьему? Я вижу одни киллер фичи - async/await, type hints, etc

Зачем тебе потоки?

Зачем в языке общего назначения потоки? Ну даже не знаю.

async/await

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

type hints

Это лишь визуальный мусор. Нормальный статических анализаторов всё равно нет для этого, зато есть полноценные типизированные языки. Зачем?

Кучу всякого ненужного сахара с закорючками втащили, всё испортили, уже не лампово.

еще раз: я железно знаю что вызвавший меня код содержит ошибку.

#!/usr/bin/python3

import traceback

def foo(val):
        if val > 10 and val < 20:
                stack = traceback.extract_stack()
                formatted = traceback.format_list(stack)
                raise Exception("Problem in %s" % str(formatted[-2]))

def fun():
        foo(15)

fun()

в Python сделано всё чтобы затруднить тестирование.

Ну да, ну да. Страдаем. Пишем иной раз такой говнкод, что тесты потом не напишешь нормально. Это все python виноват, безусловно :) Но, я боюсь на perl этот говнокод бы бы еще и нечитаемый.

И чем это отличается от

{_[0]:{'id':_[0], 'name':_[1]} for _ in filter(lambda _: _[2], map(lambda line: line.split(';'), csv.splitlines()))}

Только это ненужный говнокод, потому что в csv есть экранирование и всякие кавычки, которые надо обрабатывать, нужно брать парсер(который в питоне есть из коробки). Это всё равно что xml регулярками парсить.

Вообще есть linq-подобные библиотеки для такого говнокода.

Только на Perl можно писать читаемый код

Что ж ты даже в этот тред такого кода не принес?

средства документирования (perldoc)

Шикарный аргумент в пользу эксклюзивной пригодности языка для написания читаемого кода! И сам же его на первое место поставил.

Вообще-то чем легче читается код, тем меньше он нуждается в документировании. Я как-то работал с django-oscar, там документация была ну крайне скудная. И это мне _абсолютно_ никак не помешало, т.к. тамошний код читать не сложнее, чем документацию к коду. На perl'e же даже простейший csv парсер сделать нормально читаемым, судя по всему, задача нетривиальная.

Ну я не люблю без крайней нужны писать код с потоками, со всеми локами, гонками и прочими радостями. Это значит по-любому нужна разделяемая память и какие-то вычисления, которым одного ядра мало, очевидно это числодробилка. В остальных случая проще множиться процессами и использовать ipc по вкусу, тут много удобных вариантов. Или есть это сетевой код завязынный на IO тут GIL не проблема. Или можно писать асинхронный код.

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

По поводу js - не вижу принципиальной разницы и почему это не «выглядит инородным» там, но выглядит в питоне.

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

В этом и вся красота лора =)

ППЦ у тебя аргументы, просто ППЦ

1. лог тестирования немашиночитаем
2. лог тестирования нечеловекочитаем
3. лог фейла тестирования неинформативен и немашиночитаем

когда приходит от CI фейл лога, то одного письма с этим фейлом совершенно недостаточно.

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

а тут - обычный неинформативный exception и всё.

это именно ППЦ

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

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

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

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