Справедливости ради стоит отметить, что пример в конце, про стремительный рост китайской экономики, Гуанчжоу и «поезд со скоростью в 360 км/ч» несколько неполный. За кадром осталась убийственная экологическая ситуация.
Можно возразить, что и у нас с этим проблемы, на Байкале комбинат, и леса вырубаются, а поездов и небоскрёбов в деревнях как не было, так и нет. И это так. Но в Китае всё НАМНОГО хуже. И лично я не уверен, что хотел бы заплатить за заводы по производству всего-что-угодно, поезда и небоскрёбы такую цену.
Например, благодаря PEP 391 в Python 2.7 появился способ конфигурирования стандартного пакета логирования через словари. Примеры кофигурации представлены в YAML-нотации, а сам подход объявлен предпочтительным перед вариантом с ConfigParser-ом.
Про Paste. Я занимаюсь разработкой под Pylons, в котором PasteDeploy и PasteScript идут в качестве зависимостей. До того момента, как проект Pylons было решено забросить и начать разработку Pyramid, разработчики объявляли о намерении заменить Paste на самописный пакет Marco, в котором присутствовала возможность конфигурирования посредством YAML. Но с того момента проект успешно заглох. Переписка с разработчиками показала, что они не в большом восторге от Paste (а тому есть очень веские причины), но так как он «просто работает» и «это не высокоприоритетная задача», дорабатывать Marco в ближайшее время никто не собирается.
Когда я переводил свой проект на YAML-конфигурации без использования Paste, мне пришлось лезть и разбираться в его исходниках. Сказать, что Paste ужасен — ничего не сказать. Он изначально предлагает ущербный формат, без права выбора, и поверх этого строит свою неструктурированную кодовую базу, состоящую из хуков типа paste.deploy.converters и вложенных кусков посторонних пакетов (вроде CherryPyWSGIServer из пакета CherryPy).
В итоге, процесс конфигурирования более-менее сложного проекта с помощью Paste превращается в уродский набор инструкций на уровне python-кода вашего приложения.
Лично мне кажется, что INI прижился в среде Python-разработчиков только благодаря тому, что он очень давно существует в стандартной библиотеке (точно присутствовал уже в 1.6) и ему до недавнего времени не было абсолютно никаких альтернатив — не было других «парсеров из коробки». Но ситуация меняется. Станадртный парсер JSON, основанный на коде simplejson, появился только в версии 2.6. Дойдёт время и до включения PyYAML в стандартную поставку.
Небольшое лирическое отступление.
В сообществе Python-программистов следует всеми правдами и неправдами продавливать YAML как основной формат конфигураций. А также агитировать за игнорирование PasteDeploy и PasteScript до тех пор, пока они не избавятся от «беспредела» в своём коде.
В Micro Men показана та же история. Успешные компании в разных нишах смотрят друг на друга как на конкурентов, пытаются занять место друг друга, терпят крах, а выживают в итоге Microsoft да HP :)
Дополнительно нужно отметить, что в оригинальном (32-битном) алгоритме murmur2 есть слабые места, которые на некоторых специфичных тестовых наборах данных генерируют ~98% коллизий (!) Об этом я упоминал в Q&A — habrahabr.ru/qa/2148/
Проверкой 64 битного алгоритма на наличие подобных артефактов, на моей памяти, никто не занимался.
А так, конечно интересно посмотреть на живые тесты. Заявленные 30% форы звучат внушительно.
Я «ананас» тоже не считаю вариантом.
Из открытых платформ можно ещё выделить OpenERP (ранее звалась TinyERP) — www.openerp.com/. Написана на Python, имеет Web и GUI (основан на GTK) интерфейсы. Многие технические вопросы в ней уже решены, существует огромная база общих модулей, но никакой российской поддержки нет. В общем — хороший пример платформы, под которую никто (образно) в России не пишет.
> Кто готов взяться за первую часть — разработку самой платформы?
Людям нужна не платформа, а функциональный продукт. И попытки были, и примеры наглядные — ananas.su/ Только на моей памяти прошло уже 5 лет, а у проекта как была голая платформа, так всё и осталась.
Поэтому.
Вместо разработки очередной платформы, которых сейчас полно, лучше помогите вот этим людям — www.m-g.ru/ — организовать активное сообщество вокруг уже функционирующего продукта. Проект открыт не первый год, но на форуме тихо как в склепе.
В любом алгоритме хеширования есть вероятность коллизии, зависящая от его битности, лавинного эффекта (avalanche effect) и фактора расхождения набора хешируемых данных (fanout factor).
Я говорю про артефакты, связанные с — цитирую — «ограничение длины в 16 символов».
Конфиг из PasteDeploy. И внутри это просто жуткая мешанина. INI — ужасный формат. Paste предлагает в качестве решения пользоваться их хуками из paste.deploy.converters, что превращает процесс конфигурирования более-менее сложного проекта в уродский набор инструкций на уровне python-кода.
Можно возразить, что и у нас с этим проблемы, на Байкале комбинат, и леса вырубаются, а поездов и небоскрёбов в деревнях как не было, так и нет. И это так. Но в Китае всё НАМНОГО хуже. И лично я не уверен, что хотел бы заплатить за заводы по производству всего-что-угодно, поезда и небоскрёбы такую цену.
Если вы действительно так считаете, пожалуйста, дайте мне доступ на чтение к вашему репозиторию. Я попробую найти для себя что-нибудь полезное.
Про Paste. Я занимаюсь разработкой под Pylons, в котором PasteDeploy и PasteScript идут в качестве зависимостей. До того момента, как проект Pylons было решено забросить и начать разработку Pyramid, разработчики объявляли о намерении заменить Paste на самописный пакет Marco, в котором присутствовала возможность конфигурирования посредством YAML. Но с того момента проект успешно заглох. Переписка с разработчиками показала, что они не в большом восторге от Paste (а тому есть очень веские причины), но так как он «просто работает» и «это не высокоприоритетная задача», дорабатывать Marco в ближайшее время никто не собирается.
Когда я переводил свой проект на YAML-конфигурации без использования Paste, мне пришлось лезть и разбираться в его исходниках. Сказать, что Paste ужасен — ничего не сказать. Он изначально предлагает ущербный формат, без права выбора, и поверх этого строит свою неструктурированную кодовую базу, состоящую из хуков типа paste.deploy.converters и вложенных кусков посторонних пакетов (вроде CherryPyWSGIServer из пакета CherryPy).
В итоге, процесс конфигурирования более-менее сложного проекта с помощью Paste превращается в уродский набор инструкций на уровне python-кода вашего приложения.
Лично мне кажется, что INI прижился в среде Python-разработчиков только благодаря тому, что он очень давно существует в стандартной библиотеке (точно присутствовал уже в 1.6) и ему до недавнего времени не было абсолютно никаких альтернатив — не было других «парсеров из коробки». Но ситуация меняется. Станадртный парсер JSON, основанный на коде simplejson, появился только в версии 2.6. Дойдёт время и до включения PyYAML в стандартную поставку.
В сообществе Python-программистов следует всеми правдами и неправдами продавливать YAML как основной формат конфигураций. А также агитировать за игнорирование PasteDeploy и PasteScript до тех пор, пока они не избавятся от «беспредела» в своём коде.
Проверкой 64 битного алгоритма на наличие подобных артефактов, на моей памяти, никто не занимался.
А так, конечно интересно посмотреть на живые тесты. Заявленные 30% форы звучат внушительно.
Из открытых платформ можно ещё выделить OpenERP (ранее звалась TinyERP) — www.openerp.com/. Написана на Python, имеет Web и GUI (основан на GTK) интерфейсы. Многие технические вопросы в ней уже решены, существует огромная база общих модулей, но никакой российской поддержки нет. В общем — хороший пример платформы, под которую никто (образно) в России не пишет.
Людям нужна не платформа, а функциональный продукт. И попытки были, и примеры наглядные — ananas.su/ Только на моей памяти прошло уже 5 лет, а у проекта как была голая платформа, так всё и осталась.
Поэтому.
Вместо разработки очередной платформы, которых сейчас полно, лучше помогите вот этим людям — www.m-g.ru/ — организовать активное сообщество вокруг уже функционирующего продукта. Проект открыт не первый год, но на форуме тихо как в склепе.
Я говорю про артефакты, связанные с — цитирую — «ограничение длины в 16 символов».