То есть это получается что если программа написана на bottle разделена на несколько файликов и в каждом встречаются декораторы роутов то при возникновении ошибки потом будет много проблем?
А можно ли webob отнести к микрофреймворку подобно bottle?

alexandre
То есть это получается что если программа написана на bottle разделена на несколько файликов и в каждом встречаются декораторы роутов то при возникновении ошибки потом будет много проблем?
А можно ли webob отнести к микрофреймворку подобно bottle?

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

webob - библиотека а не фреймворк. Отличие серьезное.

Полсотни модулей - это еще совсем немного :)

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

Андрей Светлов
Ошибку воссоздать довольно легко - но еще легче забыть о такой особенности.

можете привести пример?

Это случается, когда имеем бардак в путях импорта.
Например

package
__init__.py
lib.py
utility.py
common.py
main.py

Если
1. наша utility.py может запускаться как отдельный файл
2. при этом она желает делать что-то вроде import common
- самое простое решение написать sys.path.append('..') или нечто вроде того.

Так делать неправильно - и все же я видел такой код раз за разом.
Тогда получается, что lib.py можно импортировать двумя способами:
import lib
import package.lib

Равно как utility.py на самом деле - три разных модуля: __main__, utility, package.utility.
В результате код utility.py может быть выполнен три раза.

Чтобы избежать такую ситуацию я стараюсь вообще не делать модули, которые можно запустить непосредственно.
Параметр scripts в setup.py позволяет создавать запускалки по проименованым ресурсам. В нашем случае было бы package.utility:main
И тем не менее - видел вышеприведенный мусор, и далеко не один раз.

> В результате код utility.py может быть выполнен три раза.
Жесть. Точно, проверил. Не знал.

> я стараюсь вообще не делать модули
А я не стараюсь, просто не делаю. Не вошло в привычку писать всё самостоятельно с самого низкого уровня, так что для выполнения различных команд приложения всегда используются, либо Twisted, либо Paste, либо Django, ну или ещё что-нибудь.

p.s. Не читал статью, с анг. у меня не очень да и нет особого желания. Если судить по твоим словам, то проблемы там описаны достаточно элементарные (для меня) и мне на них напороться не грозит.

..bw

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

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

> bw
> А я не стараюсь, просто не делаю
когда проект доходит до больших размеров,( и над которым работают несколько человек), с пакетами/модулями гораздо удобней

вообщем при правильных импортах, @route'ы не страшны

При правильных - да.

К слову, правильная программа работает всегда корректно. Только где они, правильные? :D

>>> я стараюсь вообще не делать модули
>> А я не стараюсь, просто не делаю
> когда проект доходит до больших размеров,( и над которым работают несколько человек), с пакетами/модулями гораздо удобней

Не до конца процитировал. Подразумевалось:

> которые можно запустить непосредственно

..bw