Python-сообщество

Chrizt
Пардон за некоторый оффтоп, но “Парадигма быдлокода” воистину smile

Самокритично )))

Chrizt
В моём лучае, как я понимаю, лучше сделать как это там… profiling, верно?

Да, профайлер позволит найти узкие места, очень полезная штука.
Но что касается классов/функций, то результат повлияет на читабельность/расширяемость кода (при ооп _как правило_ более хорошая декомпозиция кода), за счет этого будет меньше багов и т.д. Но если использовать классы, то код от этого магическим образом не станет быстрее. )

ZAN

Chrizt
Пардон за некоторый оффтоп, но “Парадигма быдлокода” воистину smile

Самокритично )))

Chrizt
В моём лучае, как я понимаю, лучше сделать как это там… profiling, верно?

Да, профайлер позволит найти узкие места, очень полезная штука.
Но что касается классов/функций, то результат повлияет на читабельность/расширяемость кода (при ооп _как правило_ более хорошая декомпозиция кода), за счет этого будет меньше багов и т.д. Но если использовать классы, то код от этого магическим образом не станет быстрее. )

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

Спасибо за саппорт.

Есть еще пара вопросов:
1. Есть ли какой-то крутой мануал по правильному профилированию?
2. Если при запросе генерируемой картинки отдавать не статичную, с диска/кеша (я бомж, не могу себе позволить сервер), а каждый раз генерировать ее заново - это сильно нагрузит мой акк на хостинге? Особенно, если картинки начнут гулять по интернету (хотлинки/встраиваемые).

Chrizt
Особенно, если картинки начнут гулять по интернету (хотлинки/встраиваемые).

Такие картинки могут и с кешем убить сервер, не говоря уже о динамической генерации.

Chrizt
1. Есть ли какой-то крутой мануал по правильному профилированию?

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

Чувствую, что шаманить мне еще придется долго с классами, так что, наверное придется пока воспользоваться советом PooH и не трогать рабочий код :) Я не забивал на Ваш совет и мне было любопытно узнать, “а что если…”.

Огромное спасибо всем за помощь и поддержку.
И спасибо ZAN за ссылку. Уже сижу, просвещаюсь, гуглю дальше.

Я думаю вы сможете определиться ответив самому себе на несколько вопросов:
1. Насколько большой проект на данный момент и на сколько большим он может стать в ближайшем будущем?
2. Сколько человек в данный момент разрабатывает проект и сколько будет разрабатывать в перспективе?
Выводы будут очевидны. Не надо писать ООП ради ООП, это не всегда полезно и хорошо размазывать простую задачу по десяткам классов с сложной иерархией, думаю что выделить основные части кода в функции будет лучше.

Это:

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

в противовес этому:

ZAN
при ооп _как правило_ более хорошая декомпозиция кода

Chrizt
Это:

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

в противовес этому:

ZAN
при ооп _как правило_ более хорошая декомпозиция кода

Это второстепенно когда есть это:

PooH
Не чините то, что не сломано ;)

Долго ли, коротко ли, но я таки переписал всю эту лабуду, даже дополнил и (возможно) улучшил =)
Получилось 300 строчек кода, и это ещё не конец.
Наконец-то сгрузил это дело в комп и сейчас буду продолжать писать уже в Aptana Studio 3, профилировать, соединять код с Django-приложением.
Спасибо за Ваши мысли, рекомендации, разъяснения и помощь.

Кстати, всё это время писал код в Kaapython на Nokia 5320 XM (s60 v3 (Symbian 9.3)) =) Весело, ага =) Иногда это было даже удобнее, чем всё время тыкаться в комп и вспоминать, на чём остановился и всякое такое.

Отвечая на вопрос непосредственно темы: конечно юзать.

Isem
Отвечая на вопрос непосредственно темы: конечно юзать.

Спасибо! =)