Несколько пожеланий, если хотите чтобы проект не был забыт на этой статье:
— Оформите код по PEP-008;
— Используйте Sphix для генерации документации вместо dir(...);
— Выложите код на github, bitbucket, whatever, раз open source;
— Зарегистрируйте пакет на PyPi (документацию там же можно хостить).
В текущем виде ничего кроме желания «переписать» оно не вызывает.
Еще мне не нравится, что вы используете os.walk(), который разбивает имя файла на части, а потом назад его собираете. Но я не нашел другого способа рекурсивно получить все файлы.
os.walk основывается на os.listdir, который оперирует понятиями root path и basename — отсюда и разделение полного пути файла/директории на части.
Оба варианта доставят массу неприятностей если дать им пройтись по коллекции HD-видео, ISO-образов и прочих гигабайтных файлов: именно для таких случаев и существует метод update.
3. Как получить список методов объекта
Поскольку функции и методы в Python являются объектами первого рода (вроде правильно написал?), то для проверки будем использовать функцию getattr, которая возвращает сам аттрибут объекта и функцию callable, которая и осуществляет проверку.
print [arg for arg in dir(Foo) if callable(getattr(Foo, arg))]
# или
print filter(lambda arg: callable(getattr(Foo, arg)), dir(Foo))
Более правильный вариант, учитывая что callable выпилили из 3.х и что вариант из примера вытащит так же все callable-атрибуты, которые не являются методами:
import inspect
print [name for name, item in inspect.getmembers(Foo) if inspect.ismethod(item)]
Да, и во всяком случае я бы так поступил. Пром. объект содержал бы Embedded данные справочных документов(страна, филиал, организация и т.п.) на момент своего создания, а все справочные данные были бы отдельным документами, из которых можно собрать еще один пром. объект. А то, что организация находится в стране Б, можно оставить ссылку на эту страну — в контексте задачи это все справочные данные. Если организация Foo передает пром.объект организации Bar, то это событие стоит зафиксировать отдельным документом — как бонус получите историю «движения» пром. объекта по организациям.
Все проще: Linking для справочных данных и Embedding для событий или тех, чья информационная целостность критична.
Данные, описывающие событие не должны каскадно меняться, поскольку описывают состояние события на определенный момент времени. Linking в этом случае нарушает его целостность и способно скомпроментировать его как факт.
Справочные данные наоборот, являются «строительными кирпичами» событий. Они могут образовывать множество связей между собой и это негативно скажется на попытке поддежания актуальности информации во всех связанных документах, если будет использован Embedding подход. Так же справочные элементы не являются каким либо событием, а просто набором атрибутов для некоего абстрактного объекта, тип которого так же закладывается в этих атрибутах.
Ну какой же это full table scan, когда list функция опирается на результатах view функции, что по сути уже предопределенный результат, который может быть размером меньше, чем все данные базы? Для реляционных это будет форматирование выборки запроса, который уже отработал и знает свой результат.
Так же list функции единственные реализуют chunked response, т.е. порционный ответ маленькими частями — show функции вроде как заявляют тот же подход, но на деле просто его эмулирут и накапливают все чанки во внутреннем стеке. При этом наоборот — если вы захотите представить результат list функции в каком-нибудь бинарном формате, то без дополнительных соглашений о параметре mime типа ;base64 и дополнительном кодировании чанков мало что хорошего получится.
— Оформите код по PEP-008;
— Используйте Sphix для генерации документации вместо dir(...);
— Выложите код на github, bitbucket, whatever, раз open source;
— Зарегистрируйте пакет на PyPi (документацию там же можно хостить).
В текущем виде ничего кроме желания «переписать» оно не вызывает.
os.walk основывается на os.listdir, который оперирует понятиями root path и basename — отсюда и разделение полного пути файла/директории на части.
А как же метаклассы? =)
Более правильный вариант, учитывая что callable выпилили из 3.х и что вариант из примера вытащит так же все callable-атрибуты, которые не являются методами:
Данные, описывающие событие не должны каскадно меняться, поскольку описывают состояние события на определенный момент времени. Linking в этом случае нарушает его целостность и способно скомпроментировать его как факт.
Справочные данные наоборот, являются «строительными кирпичами» событий. Они могут образовывать множество связей между собой и это негативно скажется на попытке поддежания актуальности информации во всех связанных документах, если будет использован Embedding подход. Так же справочные элементы не являются каким либо событием, а просто набором атрибутов для некоего абстрактного объекта, тип которого так же закладывается в этих атрибутах.
Так же list функции единственные реализуют chunked response, т.е. порционный ответ маленькими частями — show функции вроде как заявляют тот же подход, но на деле просто его эмулирут и накапливают все чанки во внутреннем стеке. При этом наоборот — если вы захотите представить результат list функции в каком-нибудь бинарном формате, то без дополнительных соглашений о параметре mime типа ;base64 и дополнительном кодировании чанков мало что хорошего получится.