Miałeś do czynienia bardzo dawno w Zope. Bierzący Zope 2.9.3 bardzo się różni od starego. Po pierwsze, z każdą wersją coraz bardziej integruje się z Zope3. Np. Zope3 wchłonął interfejsy z innego, poważnego systemu: Twisted (to ci spece od protokołów, m.in. napisali asynchroniczny serwer www, który w ogóle się nie blokuje). Szablony ZPT od dawna sa promowane w miejsce DTML.

Jeśli chodzi o CMS, to świetnym przykładem możliwości Zope jest Plone. Używam go w kilku serwisach. Jest bardzo potężny i bardzo prosty zarazem. Instalacja to 5 minut. Od ręki dostaje się kompletny system z własnym systemem autoryzacji, obiegiem dokumentów, wyszukiwarką i innymi rzeczami. Plone to przykład możliwości Zope, bo Plone to tylko "produkt" (coś w rodzaju plugina) który dynamicznie się dorzuca do Zope. Takich produktów (o różnym poziomie jakości) jest setki. Zope to duża rzecz. Nie bez powodów korzystają z niego wielkie sieci, rządy, NASA, NATO itp.

Aktualnie z innych pythonowych frameworków na fali jest Django, Pylons i TurboGears. Nie wiem czy im się przyglądałeś. Guido wydaje się sympatyzować z Django. To niezły framework. Chodzi na tym od paru lat kilka cieżko obciążonych, złożonych portali.

Czy będzie odchodzić się od typowania dynamicznego? Raczej w to nie wierzę. Guido coś przebąkiwał o dodaniu opcji określania typów, ale to jest podyktowane tylko chęcią zwiększenia wydajności interpretera i chyba to ślepa uliczka, bo interpreter nigdy nie będzie tak szybki jak kompilator. Zresztą to ma mniejsze znaczenie wobec znacznie większej szybkości pętli sprzężenia zwrotnego interpretera. To jest ważniejsze do bardziej produktywnej pracy. Moc procesorów szybko się podwaja. tego samego nie da się powiedzieć o produktywności programistów. Jest to więc czynnik ważniejszy (zgadzam się tu z Bruce Tate) Poza tym, pośród pythonistas, nikt tych dodatkowych typów nie chce i mam nadzieję że Guido to uwzględni.

Co do Ruby, to Matz coś przebąkiwał o zmianie otwartych klas w Ruby2, ale mam nadzieję że to nie wprowadzi, bo to by wywróciło do góry nogami soft, który działa w Ruby. Wtedy tylko Smalltalk chyba już by pozostał z ideą otwartych klas (tzn. można modyfikować absolutnie wszystkie obiekty, ze stringami i integerami włącznie). Duża część sukcesu Rails wynika z dużej dynamiki Rubiego (nawet większa od Pythona).

Co do C i C++, to kiedyś lubiłem w tym pisać, ale teraz nie mam serca do tego wracać od czasu jak przestawiłem się na inny paradygmat. Przestawienie się z jezyków statycznie typowanych na dynamiczne to nie tylko składnia, to inna filozofia pracy. Od Javy wciąż mnie odrzuca składnia i uciążliwość deklarowania typów i mozolność konfiguracji. Ciężkie jest życie, jak zasmakujesz pracy w Pythonie i Ruby. Nawet na PHP też trudno patrzeć, bo ma koszmarną składnię, chaotyczne funkcje, brak przestrzeni nazw i w ogóle nędzną dynamike i obiektowość (nawet PHP5).

Co do type hints w PHP5... Rozwój tego języka jest jakiś taki chaotyczny, w dużej mierze inspirowany wpierw Perlem i C++m potem Javą, czyli językami z zupełnej innej (statycznej) bajki (poza Perlem, który nie jest statycznie typowany ale ma też paskudną składnię). Mogliby popatrzeć lepiej na Rubiego i Pythona, to by trochę elegancji do kodu prowadzili.

Jakby nie było, współczenie trzeba operować kilkoma językami. Ja równolegle piszę głównie w PHP, Pythonie i Ruby. Jak będę potrzebował dopalacza, to pewnie siądę do C++ aby napisać jakieś rozszerzenie. Na razie nie mam jednak takich potrzeb.

Od testów jednostkowych raczej nie ma odwrotu bo statyczne typowanie jest za słabe aby pilnować spójności kodu. (Rails kładzie na to silny nacisk, testy jednostkowe, integracji i funkcjonalne są częścią tego frameworka i są automatycznie budowane przy próbie tworzenia jakiegokolwiek modelu czy kontrolera). Oczywiście, unit testy znacznie wygodniej się pisze w językach dynamicznych. Jeśli ten trend na extreme programming i unit testing się utrzyma, to rola interpretowanych języków dynamicznych będzie raczej tylko rosła, a nie malała.