[python] html табличка

Молодец. А что ты этим хотел сказать?

Я вот 15 минут назад поставил себе задачу написать небольшое приложение на gtkmm в QTCreator-е.

Реквестирую в тред мысль.

Выглядит как пхпшный быдлокод из-за смешения кода и разметки.

Ну а с кем кроме ЛОРа поделиться-то. Я к быдло-дневничкам не приучен )

Нууу, код, кажется, работает - почему бы и нет?

Любое количество ячеек в строках - это, я так понимаю, фича?

В любом случае, как упражнение это сделать, конечно, можно. Но зачем?

Ваш пример в виде макро для Jinja2 будет примерно так выглядеть:

{% macro format_table(title, data) %}
<table>
    <tr>
    {% for title_item in title %}
        <th>{{ title_item }}</th>
    {% endfor %}
    <tr>

{% for data_row in data %}
    <tr>
    {% for data_item in data_row %}
        <td>{{ data_item }}</td>
    {% endfor %}
    </tr>
{% endfor %}

</table>
{% endmacro %}

Да, кстати, 2 из 4 «условий», имеют отношение к coding style, однако вы ухитрились написать совершенно нечитабельный код.

Суббота, вечер, ни вижу причин не поупражняться. Про шаблоны я знаю. Но дума, что для небольшой web-based утилитки, где окромя таблички ничего больше и нету — тянуть джинжу как-то не pytonic.

PEP 8 не спасет мир. Пичаль.

Если не сложно: что конкретно не понравилось, я кажись ничем не злоупотрибил.

PEP 8 не спасет мир

Нет, не спасет - если, что его и спасет, так это здравый смысл.

Все читают PEP8 и думают, что там написано только про то сколько пробелов ставить и какие кавычки использовать.Там написано про здравый смысл.

По поводу вашего кода - да, пускай он соответствует PEP8. Но там же просто нагромождение всего!

Для начала я бы вывел c_row в отдельную функцию (format_row), которая бы определялась один раз, а не при каждом вызове table_view.

> тянуть джинжу как-то не pytonic

Если уж говорить о том, что «pythonic», а что «не pythonic», то «не pythonic» - это городить свой велосипед, когда для python есть огромное количество template-движков на просто прямо-таки любой вкус.

Но это безотносительно этого конкретного случая - я уже понял, что это - «упражнение».

Ну, Лутц, например, пишет, что лямбды надо использовать для инкапсуляции кода, который не будет использоваться повторно. При импорте format_row попадет в область видимости вызывающего модуля. Допустим, я не хочу этого.

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

Вот аналог на плюсах

QString print_table(QList<QVariant> &head,QList<QList<QVariant> > &body)
{
    #define print_cell(cell) {s+="<td>";s+=cell.toString();s+="</td>";}
    #define print_row(row) {s+="<tr>"; foreach(QVariant cell,row) print_cell(cell); s+="</tr>\n";}

    QString s="";
    print_row(head);
    foreach(QList<QVariant> list,body)
        print_row(list);
    return s;
}

Думаю, даже с кутями это будет быстрее питона. Вот только макросы внутри функции для меня странновато смотрятся. Я что-то пропустил или в Qt так принято.

> Допустим, я не хочу этого

Почему? Если из-за 'from foo import *', то так все равно делать нельзя, но если очень хочется, можно либо использовать __all__, либо назвать функцию '_format_row'.

Ну, я указал именно субъективную причину. Не хочу и все тут. Но не суть. Другой вариант: в модуле много однострочных функций. На каждую по две строчки плюс отступ до и после, тоже в две строки. И что это — PEP 8 или здравый смысл?

> На каждую по две строчки плюс отступ до и после, тоже в две строки.

Две строчки не выйдет. По крайней мере еще одна строка нужна на docstring. Вы же документируете свой код? А так нормально, вполне соответствует, мне кажется.

Вот только макросы внутри функции для меня странновато смотрятся. Я что-то пропустил или в Qt так принято.

Нет. Так не принято. Максимум ты такое можешь увидеть у фимозных сишных пуристов. Просто я пытался сделать код компактнее. Я думал, что вокруг компактности весь разговор. Для себя я бы сделал через дополнительные функции. Что-то вида:

static void print_cell(QString& s,QVariant cell)
{
    s+="<td>";
    s+=cell.toString();
    s+="</td>";
}

static void print_row(QString& s,QList<QVariant> &row)
{
    s+="<tr>";
    foreach(QVariant cell,row) print_cell(s,cell);
    s+="</tr>\n";
}

QString print_table(QList<QVariant> &head,QList<QList<QVariant> > &body)
{
    QString s="";
    print_row(s,head);
    foreach(QList<QVariant> list,body)
        print_row(s,list);
    return s;
}

Хотя функции мелковаты.

Да, докстринг. Можно даже две строчки. Что-то я помню было про выделение завершающих кавычек на отдельную строку. Не утверждаю, а проверять лень. Так к чему я это все: стоит ли делать все эти отступы и писать докстринги для однострочника, да еще со вполне понятным названием: foramat_row.

В плюсах я не стал бы гоняться за компактностью. Язык на это явно не рассчитан.

А вот так, кстати, заработает: s+= «<tr>» + foreach(QVariant cell,row) print_cell(s,cell) + «</tr>»; ?

Еще помню в бусте были какие-то лямбды. Сам ни разу не пробовал.

Отвечу сам - нет. Я имел ввиду s += «<td>» + cell.toString() + «</td>»;

> стоит ли делать все эти отступы и писать докстринги

Я считаю, что если вы задаетесь этим вопросом, значит абсолютно точно стоит.

вот из-за такого подхода потом бектрейсы вызовов заставляют шевелится волосы на всех частях тела :).