Действительно ли Опоры готовы к предприятию? [закрытый]
Настоящей проблемой здесь является отсутствие пробела между двумя операторами ! и --.
Я не знаю, почему люди думают, что после оператора ! нельзя использовать пробел. Я думаю, что это происходит из-за строгого применения механических правил пробела вместо здравого смысла. Почти все стандарты кодирования, которые я видел, запрещают пробелы после всех унарных операторов, но почему?
Если когда-либо был случай, когда вам явно нужно это пространство, это один.
]Рассмотрим этот фрагмент кода:
if (!--pending)
done(null, results);
Мало того, что ! и -- смешиваются вместе, у вас также есть (, чтобы ударить их. Неудивительно, что трудно сказать, что с чем связано.
Чуть больше пробелов делает код намного более понятным:
if( ! --pending )
done( null, results );
Конечно, если вы привыкли к механическим правилам, таким как «без пробела внутри паренсов» и «без пробела после унарного оператора», это может показаться немного чужим.
Но посмотрите, как лишние пробелы группируют и разделяют различные части выражения и выражения if: у вас есть --pending, поэтому -- явно является своим собственным оператором и тесно связан с pending. ]. (Он уменьшает pending и возвращает уменьшенный результат.) Затем вы отделили ! от этого, так что это, очевидно, отдельный оператор, сводящий на нет результат. Наконец, у вас есть if( и ), окружающие все выражение, чтобы сделать его выражением if.
И да, я убрал пробел между if и (, потому что ( принадлежит к if. Этот ( не является частью какого-то синтаксиса (!--, как кажется в оригинале, а часть ( - синтаксиса самого оператора if.
Пробелы здесь служат для передачи значения вместо того, чтобы следовать какому-либо механическому стандарту кодирования.
7 ответов
Когда дело доходит до корпоративной готовности, я не уверен, насколько более готовым может быть стек, использующий Pylons с SQLAlchemy, в мире Python. Вы готовы к массивным устаревшим базам данных с сумасшедшими схемами (что является обычным явлением в крупных корпоративных мирах), где Django просто разваливается по швам. Конечно, в Django вы могли по-прежнему использовать SQLAlchemy, но тогда все инструменты Django contrib разваливаются, поскольку все они полагаются на предположение, что вы будете делать что-то «Django».
Pylons имеет существует с середины 2005 года и никуда не денется. На самом деле он довольно зрелый, и у него довольно медленный и твердый график выпуска - 6-10 месяцев между выпусками, с довольно небольшим количеством тестов. Один из основных разработчиков Pylons также является разработчиком на Jython, гарантируя, что Pylons может работать на JVM (что помогает переносить приложения на основе Pylons в корпоративные среды, враждебные к вещам, которые нельзя упаковать в файл WAR для развертывания).
Что касается некоторых других «ответов» здесь, вопрос заключается в том, готовы ли Pylons к корпоративной среде. Я понятия не имею, почему другие не смогли прочитать этот вопрос и вместо этого решили начать проповедовать свою любимую структуру. Довольно глупо говорить, что вы должны использовать Django / Zope / Grok, потому что он имеет "большее распространение" или "большее сообщество", если это критерий, выбор должен быть PHP, что заставляет сообщества Django и Zope выглядеть немного паршиво по сравнению . Pylons определенно имеет достаточно большое сообщество, чтобы поддерживать себя,
Я бы сказал, что если вы беспокоитесь о поддержке «корпоративного уровня», вам следует больше обратить внимание на Django. Хотя вы можете спорить об относительных технических достоинствах этих двух фреймворков, нет никаких сомнений в том, что Django пользуется большим спросом, и довольно много крупных компаний используют его.
Еще одна причина заключается в том, что IBM (только в последней паре дней) выпустила драйвер Django для DB2 , поэтому у вас не должно возникнуть проблем с использованием существующей базы данных с Django ORM.
определение готовности предприятия.
Кроме того, если мы говорим о масштабируемости, я бы скажем, у вас есть лучший шанс с sqlalchemy, поскольку вы можете при необходимости перейти к необработанному sql. Принимая во внимание, что активный шаблон записи, кажется, является причиной большой ценности высокоуровневых фреймворков, это может привести к проблемам масштабируемости, если вы собираете все вместе.
Конечно, «готовность к предприятию» для некоторых людей означает сложность и дороговизну , если это ваше определение, то я бы сказал, что никакая веб-платформа Python не будет соответствовать вашим потребностям.
Я бы второй вызов использовал Django. На самом деле я предпочитаю Pylons, потому что он намного компактнее, чем Django, но, учитывая, что вы указали "готово к работе", я думаю, что вы можете застраховаться в сторону более крупной структуры и носить с собой кухонную раковину.
Если вам нужны фреймворки, которые вряд ли скоро исчезнут, посмотрите на Django и одну из фреймворков в сообщество Zope (Grok, BFG, Zope3). Zope имеет большое сообщество, существует уже более десяти лет и не собирается уходить в ближайшее время, и является питательной средой для многих новых интересных веб-технологий Python. Django новее и только недавно вышел в версии 1.0, но у него очень большое сообщество, и он также останется более или менее навсегда.
+1 для Django
Pylons - хороший фреймворк, но вам нужно будет согласовать все компоненты, чтобы создать свою собственную архитектуру, поэтому я думаю, что это больше подходит для более компактных проектов. Для чего-то большего я предлагаю Django, который, как известно, работает на некоторых крупных сайтах.
I consider a piece of software enterprise ready when it has stability and support.
I believe that Pylons/Python is stable. There are a load of sites using Pylons (including one of the highest traffic'ed sites, reddit.com).
Support wise I'd consider aspects like how easy it is to hire people who know Pylons or to purchase support contracts. This is a bit harder. If you plan to support in house Pylons is more than ready to go. If you are looking for support so that you have someone to take liability when the software breaks you might want to look elsewhere.