Chciałbym krótko wypunktować co wyróżnia Pylons spośród innych frameworków - nie tylko Pythonowych.

• Twórcy nie wstydzą się zapożyczać dobrych i sprawdzonych pomysłów z innych projektów - przez co nie muszą ponownie “odkrywać koła”
• Pylons oparty jest w większości (tam gdzie to było możliwe) na gotowych i sprawdzonych komponentach. Autorzy nazywają go megaframeworkiem ponieważ kod Pylons to tylko odpowiednie dostosowanie innych frameworków do bezproblemowej współpracy. O takich rozwiązaniach mówi się często “klej”.
• Framework jest w pełni kompatybilny z WSGI. Oparcie na WSGI ułatwia integrację między aplikacjami lub frameworkami korzystającymi z WSGI (nie ważne czy zostały stworzone w Pylons)
• Szybkość rozwijania oprogramowania - minimalizacja czasu programistów. Tak jak w Railsach skrypty tworzą za nas schemat katalogów i umieszcza w nich odpowiednie pliki. Pylons korzysta ze zintegrowany serwera WWW (Paste), który ułatwia szybkie sprawdzanie wprowadzonych zmian. Więcej o pomocnych rozwiązaniach w “szczegółach”.
• Pylons jest rozwijany przez doświadczonych programistów Pythona

Trochę szczegółów:

• ORM - do wyboru mamy SQLAlchemy, który staje się powoli najpopularniejszym ORMem Pythonowym (tak naprawdę SQLAlchemy to nie tylko ORM) albo trochę łatwiejszy dla początkujących SQLObject. Obydwa rozwiązania dają całkowitą abstrakcję od SQLa i przenośność na wszystkie obsługiwane silniki baz (czego nie zapewnia Railsowy ActiveRecord). SQLAlchemy jest projektem dużo młodszym przez co wspiera mniej baz (PostgreSQL, MySQL, SQLite, Oracle oraz na dziś w trakcie rozwijania MSSQL i Firebird). SQLObject jest na rynku od dawna. Jest sprawdzony i stabilny. Wspierane silniki baz to: PostreSQL, MySQL, SQLite, Oracle, MSSQL, Firebird, MAX DB (SAP DB), Sybase. Więcej szczegółów o tych rozwiązaniach i używaniu ich w Pylons niedługo.
• Autentykacja/autoryzacja - twórcy Pylons wzięli tu sprawy w swoje ręce i stworzyli AuthKit. AuthKit rozwijany jest niezależnie od Pylons ale ma ułatwienia integracji z Pylons (np gotowe modele dla ORMa). AuthKit to w skrócie tylko API, którym możemy sprawdzać odpowiednie zależności (np czy użytkownik się zalogował, czy ma dane prawa itp) oraz middleware, który reaguje odpowiednio na dane zawarte w WSGI. AuthKit można spiąć z bazą danych, LDAP, plikami tekstowymi lub jakimikolwiek obiektami Pythonowymi, które spełnią odpowiednie wymagania (o tym niedługo). AuthKit wspiera autentykację przez basic HTTP/1.0, digest HTTP/1.1, formularze, OpenID(PL), forwarding(oddelegowanie), lub daje możliwość zdefiniowania własnych zasad. Poza autentykacja AuthKit to również autoryzacja: użytkownicy, grupy, role, prawa O AuthKit w Pylons postaram sie napisać niedługo.
• Szablony - podstawowym systemem sa szablony Myghty, możemy jednak używać Cheetah, Genshi, Kid czy popularne ostatnio i bardzo wydajne Mako.
  
• Zarządzanie formularzami i walidacja: FormEncode, ToscaWidgets w prosty sposób umożliwiają stworzenie zasad walidacji danych, ułatwiają i automatyzują tworzenie formularzy.
• URLe - dobrze znany i bardzo elastyczny system Routes z Ruby on Rails sportowany na Pythona i prowadzony jako oddzielny projekt. Routes umożliwia wprowadzenie abstrakcji do mapowania URL -> kontroler/widok. Zamiast wprowadzać sztywne URLe do szablonów, lub mapować urle bezpośrednio na nazwy widoków odwołujemy sie abstrakcyjnie: url_for(controller=‘main’, action=’say_hello’) kod zwróci różne URLe w zależności od tego jak będą zdefiniowane drogi. Drogi możemy też nazywać - odsyłam do dokumentacji.
• AJAX / JavaScript - tu również z pomocą przybyły Railsy. Twórcy Pylons odtworzyli większość (może wszystkie, nie jestem pewien) WebHelpery. Jeżeli kiedyś korzystałeś z helperów w Railsach to wiesz, że ciężko przecenić ich wygodę.
• Dystrybucja aplikacji - Pylons wspiera pakowanie aplikacji w pakiety z zależnościmi zwane EGG (to taki odpowiednik Debianowych DEBów lub RPMów ew GEMów w Rubym). Możesz w konfiguracji określić jakich komponentów Twoja aplikacja wymaga (np SQLAlchemy, Mako, Routes). Sama aplikacja może zostać spakowana w plik egg i umieszczona np na stronie autora skąd bedzie zainstalowana razem z zależnościami przez easy_install (odpowiednik apt-get, lub gem)
• Debugging - gdy wyrzucony jest wyjątek, możemy używać interaktywnej konsoli Pythona dostępnej przez przeglądarke, która działa na obiektach, które były w trakcie wyrzucenia wyjątku. Jest również wygodny dostęp do logów. Bardzo ciekawym rozwiązaniem jest też logowanie linków do konsoli debuggowania w logach przy wywołaniach AJAXowych (zazwyczaj jeśli przy wywołaniu XHR wyrzucony został wyjątek wizualnie nic się nie zmienia i nie wiadomo co się stało)
• Testowanie aplikacji - system unittestów podobny jest do tych z Railsów
• Zautomatyzowane tworzenie dokumentacji do projektu - wiem, że Pylons wspiera takie rozwiązanie. Szczerze mówiąc jeszcze nie wiem na ten temat wiele wiec odsyłam do dokumentacji.
• Internacionalizacja - Pylons do tego celu używa Gettexta. Rozwiązanie to jest wydajne, sprawdzone i powszechne. Wystarczy pamiętać o tym by teksty, które mają być tłumaczone zawierać w _(”tekst”). Więcej informacji znajduje się tu.

Sporo tego wyszło i pewnie coś wartego uwagi przeoczyłem. Proszę o komentarze jeżeli tak, będę ten wpis uaktualniał.

Niedługo postaram się przygotować benchmark frameworków Pythonowych. Uprzedzam, że zdaję sobię sprawę z tego, że takie benchmarki nie są miarodajne ale dają przynajmniej pogląd. (i tak wiem, że Daniel powie, że to zupełnie bez sensu:))