Jos kehität verkkosovellusta ja olet valinnut Pythonin kieleksi sen rakentamiseksi, se on älykäs liike. Pythonin kehityskypsä, vankat kirjastot ja laaja käyttömahdollisuus reaalimaailmassa ovat auttaneet tekemään siitä verkkokehityksen tarpeettoman.
Nyt tulee vaikea osa: Valitse yksi monista saatavilla olevista Python-verkkokehyksistä. Määrä ei vain kasva, mutta voi olla vaikea löytää sopivinta käyttötapaustasi. Jos rakennat nopeasti ja likaisen REST-sovellusliittymän, sinun ei tarvitse missään lähellä putkistoa ja johdotusta, jota tarvitaan täydelliseen, käyttäjäkohtaiseen sovellukseen, jossa on sisäänkirjautumiset, lomakkeiden validoinnit ja latausten käsittely.
Liittyvä video: Yksinkertaisen verkkosovelluksen luominen Pythonilla ja Flaskilla
Tässä yhteenvedossa tutkitaan 13 yleisimmin käyttöönotettua Python-verkkokehystä. Panemme merkille, minkä tyyppisiä verkkosovelluksia kukin soveltuu parhaiten rakentamiseen, ja selvitämme, miten ne pinotaan toisiaan vastaan näillä kuudella alueella:
Asennus: Kuinka helppoa tai suoraviivaista on kehyksen luominen - projektit, jotka eivät vaadi muodollista asennusta (se voidaan yksinkertaisesti pudottaa olemassa olevaan projektiin mukana olevana moduulina), vaativat alkuun vain vähän kattilaa tai mukana tulee jonkinlainen esimääritetty asennus saa ylimääräisiä pisteitä.
Dokumentointi: Lähes jokaisessa kunnollisessa Python-projektissa on dokumentaatio, joka käy läpi asennuksen, havainnollistaa peruskäyttötapauksia ja antaa tietoja sovellusliittymistä. Tässä annamme korkeammat arvosanat kehyksille, jotka osoittavat, kuinka koko sovellus luodaan osana opetusohjelmaa, sisältävät yleisiä reseptejä tai suunnittelumalleja ja muuten ylittävät velvollisuuden (esimerkiksi antamalla tietoja sovelluksen ajamisesta). Python-muunnoksen alla, kuten PyPy tai IronPython).
Johto: Tämä on suhteellinen pisteet, mikä osoittaa kuinka paljon työtä tarvitaan kehyksen määrittämiseen ja ylläpitoon. Pienimmät kehykset pisteet tässä oletusarvoisesti.
Alkuperäiset ominaisuudet: Kuinka monta paristoa mukana? Korkeammat pisteet menevät kehyksiin, jotka tarjoavat natiivia tukea kansainvälistymiselle, HTML-malleille ja tiedonsiirtokerrokselle. Pisteet menevät myös kehyksiin, jotka käyttävät natiivisti Pythonin äskettäin käyttöönotettua natiivia tukea asynkronisille I / O-operaatioille.
Turvallisuus: Kehykset, jotka tarjoavat alkuperäisiä suojaustoimenpiteitä, kuten sivustojen välisen pyynnön väärentämisen (CSRF) suojaus ja istuntojen hallinta salatuilla evästeillä, saavat korkeamman arvosanan.
Skaalautuvuus: Suurin osa Python-kehyksistä voi hyödyntää Geventin tai Gunicornin kaltaisia projekteja mittakaavassa. Tässä tarkastellaan kehykselle ominaisia ominaisuuksia, jotka edistävät skaalautuvuutta, kuten ulostulo ja sivu-fragmenttien välimuisti.
Jos olet utelias suorituskyvyn vertailuarvoihin, tutustu TechEmpowerin meneillään olevaan kokeilusarjaan, jossa verrataan useita verkkokehyksiä eri tehtäviin, GitHubiin lähetettyihin koodeihin ja menetelmiin ja niitä arvioidaan jatkuvasti uudelleen. Kaikkia tämän keskustelun kehyksiä ei analysoida siellä, mutta on mahdollista saada hyvä käsitys siitä, mitkä kehykset toimivat parhaiten millaisilla kuormilla.
Tarkastelemme kaikkiaan 13 kehystä. Viisi näistä - CubicWeb, Django, Web2py, Weppy ja Zope2 - noudattavat "keittiön pesuallas" -menetelmää, pakaten useimpiin kaikkiin ominaisuuksiin, joita voit kuvitella tarvitsevasi verkkosovelluksia varten. Loput kahdeksan kehystä - Bottle, CherryPy, Falcon, Flask, Pyramid, Tornado, Web.py ja Wheezy.web - tarjoavat minimalistisemman otteen, kaupankäynnin massan ja täydellisyyden yksinkertaisuuden ja helppouden vuoksi.
Aloitetaan raskaansarjoista.
Raskaat Python-verkkokehykset
CubicWeb
CubicWebiä laskutetaan "semanttiseksi verkkosovelluskehykseksi, joka suosii uudelleenkäyttöä ja olio-suuntautunutta suunnittelua". Se on kiehtova järjestelmä - kuten Rick Grehan totesi tarkastellessaan sitä vuonna 2011 -, joka korostaa abstraktien ja uudelleenkäytettävien "kuutioiksi" kutsuttujen koodilohkojen käyttöä, mutta se voi olla joillekin kehittäjille liian abstrakti tai omaperäinen.
Kuutiot ovat ohjelmistokomponentteja, joissa on skeema (tietomalli), entiteetit (ohjelmointilogiikka) ja näkymät. Kokoamalla useita kuutioita, joista kukin suorittaa oman tehtävänsä, voit säveltää ohjelmistosovelluksia käyttämällä omaa ja muiden koodia uudelleen.
Ytimessä CubicWeb tarjoaa perustelineet, joita kaikki verkkosovellukset käyttävät: "arkisto" datayhteyksiä ja tallennusta varten; "verkkomoottori" HTTP-peruspyyntöjen / -vastausten ja CRUD-toimintojen suorittamista varten; ja kaavio tietojen mallintamiseksi. Kaikki tämä on kuvattu Python-luokan määritelmissä. Voit määrittää ja hallita CubicWeb-ilmentymiä työskentelemällä komentorivityökalulla, joka on samanlainen kuin Django.
CubicWeb ei näytä käyttävän Python 3: n natiivia asynkronointitoimintoa. Liikenneympyrän tapa sisällyttää asynkronointi olisi käyttää cubicweb.pyramid-moduulia Pyramid-kehyksen käyttämiseen verkkopalvelimena ja piirtää Pyramidin haarukkaan, joka käyttää asynkronointirakenteita. Mutta kaikki suoraviivaisempi näyttää toistaiseksi ulottumattomissa.
Voit hakea tai käsitellä pysyviä tietoja CubicWeb-sovelluksessa käyttämällä relaatiokyselykieliä (RQL), joka käyttää epämääräisesti SQL: n kaltaista syntaksia, mutta on mallinnettu W3C: n SparQL: n mukaan. CubicWebin perustelut tälle ovat jälleen abstraktio: RQL tarjoaa erittäin irrotetun reitin toisiinsa eri tietolähteiden välillä. Mutta kun se toteutetaan, rakentamalla kyselyjä manuaalisesti merkkijonoiksi, se tuntuu todennäköisesti vanhentuneelta kehittäjille, jotka ovat tottuneet ORM: iin.
CubicWebin käytössä on muita esteitä. Ensinnäkin, asennus voi olla hankalaa. Koska CubicWebillä on paljon riippuvuuksia, on parasta käyttää sitä pip asennus hakemaan ne kaikki. Saatat joutua myös suorittamaan tietyn määrän manuaalista säätämistä paikalliseen ympäristöön. Tämä on jyrkässä ristiriidassa muiden kehysten kanssa pip asennus tai kehyksen koodin pudottaminen toisen projektin alikansioon on kaikki mitä tarvitaan.
Toinen mahdollinen kysymys on natiivimallin moottorin puuttuminen; HTML: n luominen jätetään kehittäjälle. Voit voittaa tämän käyttämällä kolmannen osapuolen mallijärjestelmää, kuten Jinja2, tai valitsemalla kuutio, joka tarjoaa työkaluja verkkokäyttöliittymille, kuten Boostrap HTML -kehykselle.
Yksi pitkäaikainen ongelma CubicWebissä - Python 3 -tuen puute - on ratkaistu. Kesäkuusta 2016 ja versiosta 3.23 Python 3 -tuki laskeutui CubicWebiin lukuun ottamatta Twistedin kaltaisia moduuleja, joita ei itse ole täysin siirretty.
Kuten Web2py, CubicWeb viittaa sen pitkään dokumentaatioon "kirjana". CubicWebin epätavallisen lähestymistavan selittäminen vie aikaa, osoittaa joidenkin perussovellusten rakentamisen, sisältää API-viitteitä ja yleensä pyrkii olemaan erityinen.
Django
Vuosikymmenen aikana ja muutoksessa Djangon ilmestymisen jälkeen siitä on tullut yksi Pythonin yleisimmin käyttöönotetuista kehyksistä verkkosovellusten luomiseen. Djangossa on suurin osa tarvitsemastasi akusta, joten se nojaa enemmän suurten sovellusten rakentamiseen kuin pienet.
Liittyvä video: Yksinkertaisen verkkosivuston luominen Djangon kanssa
Monien vuosien istumisen jälkeen versiossa 1.x Django teki äskettäin version kolhun desimaalipilkun vasemmalle puolelle. Suurin muutos Django 2.0: ssa on, että kehys toimii nyt vain Python 3.4: n ja sitä uudempien versioiden kanssa. Ihannetapauksessa sinun pitäisi silti käyttää Python 3.x -ohjelmaa, joten ainoa syy käyttää Djangon 1.x-haaraa on, jos olet juuttunut vanhaan Python-versioon.
Keskeinen osa Djangon vetoomuksessa on käyttöönoton nopeus. Koska se sisältää niin paljon kappaleita, joita tarvitset keskimääräisen verkkosovelluksen kehittämiseen, voit liikkua nopeasti. Reititys, URL-jäsentely, tietokantayhteydet (mukaan lukien ORM), lomakkeiden tarkistus, hyökkäyssuojaukset ja mallit ovat kaikki sisäänrakennettuja.
Löydät rakennuspalikoita yleisimmille verkkosovellustilanteille. Esimerkiksi käyttäjien hallinta löytyy useimmilta verkkosivustoilta, joten Django tarjoaa sen vakioelementtinä. Sen sijaan, että tarvitsisit luoda oman järjestelmän käyttäjätilien, istuntojen, salasanojen, sisäänkirjautumisten / uloskirjautumisten, järjestelmänvalvojan oikeuksien ja niin edelleen seuraamiseen, Djangolla on nämä ominaisuudet natiivisti. Niitä voidaan käyttää sellaisenaan tai laajentaa kattamaan uudet käyttötapaukset minimaalisella työmäärällä.
| CubicWeb | Django | Web2py | Weppy | Zope2 | |
|---|---|---|---|---|---|
| Lisenssi | LGPL | BSD | LGPLv3 | BSD / LGPLv3 [1] | Zope Public License |
| Natiivi HTML-mallintamisjärjestelmä | Joo | Joo | Joo | Joo | Joo |
| Alkuperäinen ORM / tiedonhallinta | Joo | Joo | Joo | Joo | Joo |
| Laajennuskirjasto | Joo | Joo | Joo | Joo | Joo |
| Lomakkeen vahvistus | Joo | Joo | Joo | Joo | Kyllä [2] |
| Sivustojen välinen pyyntö väärentämisen estämiseksi | Joo | Joo | Joo | Joo | Joo |
| Käyttäjien hallinta / roolipohjainen käyttöoikeus | Joo | Joo | Joo | Joo | Joo |
| Python 3 -tuki | Joo | Joo | Ei | Joo | Ei |
| Kaavamuutokset tietomalleille | Joo | Joo | Joo | Joo | Ei |
| Vastausvälimuisti | Ei | Joo | Joo | Joo | Joo |
| Kansainvälistymisen tuki | Joo | Joo | Joo | Joo | Joo |
| Native WebSockets -tuki | Ei | Ei [3] | Joo | Ei | Ei |
| Interaktiivinen kehitysympäristö | Joo | Ei | Joo | Ei | Joo |
Djangolla on järkeviä ja turvallisia oletuksia, jotka auttavat suojaamaan verkkosovellustasi hyökkäyksiltä. Kun sijoitat muuttujan sivumalliin, kuten HTML- tai JavaScript-merkkijonoon, sisältöä ei renderöidä kirjaimellisesti, ellet nimenomaisesti nimeä muuttujan esiintymää turvalliseksi. Tämä itsessään vähentää monia yleisiä sivustojen välisiä komentosarjoja. Jos haluat suorittaa lomakevarmistuksen, voit käyttää kaikkea yksinkertaisesta CSRF-suojauksesta täysimittaiseen kenttäkohtaiseen validointimekanismiin, joka palauttaa yksityiskohtaisen virhepalautteen.
Niin monipuolinen ja laaja ominaisuus kuin Django's, ei olisi kovin hyvä ilman vankkaa dokumentaatiota sen mukana. Djangon dokumentointisivusto tarkastelee kehyksen kaikkia näkökohtia useista näkökulmista. Työskentely Python 3: n tai muun kielen makujen kanssa, suojaaminen oikein, yleisten verkkosovelluskomponenttien (kuten istunnot tai sivutukset) käyttöönotto, sivustokarttojen luominen - ne kaikki kuuluvat. Sovelluksen jokaisen kerroksen - mallin, näkymän ja mallin - sovellusliittymät kuvataan myös yksityiskohtaisesti.
Suurella voimalla on kuitenkin suuri monimutkaisuus. Django-sovellusten maine on erittäin raskas, ja niissä on paljon liikkuvia osia. Jopa yksinkertainen Django-sovellus, jolla on vain pari reittiä, vaatii melkoisen määrän kokoonpanoja käynnistyäkseen. Jos työsi on tehdä vain muutama yksinkertainen REST-päätepiste, Django on melkein varmasti ylivoimainen.
Djangolla on myös omituisuuksia. Esimerkiksi sivumallit eivät voi käyttää soitettavia. Esimerkki: Voit ohittaa {{käyttäjänimi.nimi}} komponenttina mallipohjassa, mutta ei {{user.get_name ()}}. Se on yksi tavoista, joilla Django varmistaa, että mallit eivät tee tahattomasti ikäviä asioita, mutta nämä rajoitukset voivat olla hämmentäviä, jos et ole valmis niihin. Vaikka kiertotapoja on, niillä on taipumus maksaa veroa suorituskyvystä.
Djangon ydin on synkroninen. Yksi tapa lisätä asynkronointikäyttäytymistä on kuitenkin Django Channels -projekti. Tämä projekti, virallinen Django-lisäosa, lisää asynkronisen yhteyden ja pistorasioiden käsittelyn Djangoon säilyttäen samalla Djangon ohjelmointiaidot.
Web2py
Ruby-maailmassa Ruby on Rails on tosiasiallinen verkkokehys. DePaulin yliopiston tietojenkäsittelytieteen professori Massimo Di Pierro sai Railsin innoittamana luoda Pythonissa verkkokehyksen, joka oli samalla tavalla helppo asentaa ja työskennellä. Tuloksena on Web2py.
Web2py: n suurin vetovoima on sen sisäänrakennettu kehitysympäristö. Kun määrität Web2py-esiintymän, sinulle annetaan verkkokäyttöliittymä, lähinnä online-Python-sovellusten muokkausohjelma, jossa voit määrittää sovelluksen komponentit. Tämä tarkoittaa tyypillisesti mallien, näkymien ja ohjaimien luomista, joista kukin on kuvattu Python-moduulien tai HTML-mallien kautta. Muutamassa esimerkkisovelluksessa Web2py on valmiina. Voit erottaa ne toisistaan nähdäksesi, miten ne toimivat, tai hyödyntää niitä aloitusmalleina omien sovellusten luomiseen.
Kehittäjät ottavat Web2py: n käyttöön yleensä lataamalla sen lähdekoodin ja käyttämällä sitä. Mutta vähemmän teknisten käyttäjien Windows- tai MacOS-käyttäjille Web2py: n tekijät tarjoavat versioita, jotka ovat pohjimmiltaan erillisiä palvelimia. Lataa, pura ja suorita yksi näistä versioista, ja sinulla on paikallinen verkkopalvelin, johon on sisäänrakennettu valmiiksi määritetty kopio Web2py: stä. Tämä on hieno tapa saada jalka Web2py-sovelluksen luomiseen, joka voidaan sitten ottaa käyttöön muualla tarpeen mukaan.
Web2py: n verkkokäyttöliittymä on rakennettu Bootstrap 2.16.1: llä, joten se on helppo silmissä ja helppo navigoida. Selaimen sisäinen muokkausohjelma ei korvaa täydellistä IDE: tä, mutta siinä on hyödyllisiä apuvälineitä, kuten rivinumerointi ja Python-syntaksin korostus (mukaan lukien automaattinen sisennys). Mukana on myös nopea web-käyttöliittymä Python-kuoreen, joten voit olla yhteydessä Web2py: hen komentoriviltä tarvittaessa - mukava myönnytys asiantuntijoille.
Web2py: ssä käytetty tiedonsiirtojärjestelmä toimii hieman eri tavalla kuin Djangon ORM ja muut sen innoittamat ORM: t (kuten Peewee). Nämä järjestelmät käyttävät Python-luokkia mallien määrittelemiseen, joissa Web2py: ssä käytetään konstruktoritoimintoja, kuten määritä_taulukko mallien ilmentämiseksi. Suurin osa näistä eroista kärsii todennäköisesti vain ihmisistä, joilla on jo kokemusta yhdestä ja jotka alkavat käyttää toista; he ovat suunnilleen yhtä monimutkaisia uusille tulokkaille. Sinulla ei todennäköisesti ole ongelmia Web2py: n liittämisessä tietojen tarjoajaan, koska se puhuu melkein kaikkien olemassa olevien suurten tietokantojen kanssa.
Todella hyödyllinen tietokantaan liittyvä toiminto on kyky luoda kaavio malleista, sitä parempi visualisoida mallien suhde toisiinsa. Sinun on kuitenkin asennettava pygraphviz-kirjasto kyseisen ominaisuuden ottamiseksi käyttöön.
Web2py toimittaa monia muita ammattilaiskomponentteja: kansainvälistystoiminnot, useita välimuistimenetelmiä, kulunvalvonnan ja valtuutuksen sekä jopa käyttöliittymän vaikutukset (esimerkiksi lomakkeiden päivämääränvalitsimen) integroidun tuen avulla jQuerylle ja AJAX: lle. Mukana ovat myös ulkoisen ja sisäisen väliohjelmiston koukut, vaikka et saa käyttää väliohjelmistoa korvaamaan Web2py-ydintoiminnot.
Yksi Web2py: n merkittävä rajoitus on, että se on yhteensopiva vain Python 2.x: n kanssa. Ensinnäkin tämä tarkoittaa, että Web2py ei voi käyttää Python 3: n asynkronisyntaksia. Jos luotat kahteen ulkoiseen kirjastoon, jotka ovat yksinomaan Python 3: n käytössä, sinulla ei ole onnea. Web2py Python 3 -yhteensopivuus on kuitenkin parhaillaan käynnissä, ja se on hyvin lähellä valmistumista tämän kirjoituksen jälkeen.
Ei ole ihme, että Web2py: n dokumentaatioista käytetään nimitystä "kirja". Ensinnäkin se kattaa hämmästyttävän määrän materiaalia Web2py: ssä, Pythonissa ja molemmissa käytetyissä asennusympäristöissä. Toiseksi, se on kirjoitettu helposti saavutettavalla, narratiivisella tyylillä. Kolmanneksi siinä puhutaan perusteellisesti yhteisistä sovellusten rakentamisen skenaarioista. Esimerkiksi jQueryn (mukana Web2Py) käytöstä AJAX-sovellusten rakentamiseen on koko luku.
Weppy
Weppy tuntuu puolivälissä olevalta merkiltä pullon vähäisen yksinkertaisuuden ja Djangon täydellisyyden välillä. Vaikka Weppy-sovelluksen kehittämisessä on Flashin suoraviivaisuus, Weppyssä on monia Djangossa olevia ominaisuuksia, kuten tietokerrokset ja todennus. Siten Weppy sopii sovelluksiin, jotka vaihtelevat erittäin yksinkertaisista vaatimattomasti hienostuneisiin.
Ensi silmäyksellä Weppy-koodi näyttää paljon, kuten pullo- tai pullokoodi. Muutamia ohjeita tarvitaan yhden reitin perussivuston käyttöönottoon. Reittejä voidaan kuvata toimintosuunnittelijoiden kautta (helppo tapa) tai ohjelmallisesti, ja syntaksi sen tekemiseen kulkee läheisesti pullon / pullon kanssa. Mallinnus toimii suunnilleen samalla tavalla, lukuun ottamatta pieniä syntaksimuunnelmia.
Weppy eroaa muista kehyksistä sisällyttämällä joitain ominaisuuksia, jotka ne sisältävät vain laajennuksina tai lisäosina. Esimerkiksi pullossa tai pullossa ei ole sisäänrakennettua ORM: ää tai tiedonhallintajärjestelmää. Weppy sisältää ORM: n, vaikkakin pyDAL-projektiin perustuvan, eikä paljon suositun SQLAlchemyn sijaan. Weppy tukee jopa kaavamuutoksia, joita Django tukee osana ORM: ää (myös Djangon siirtojärjestelmä on paljon automatisoitu). Vaikka Weppyllä on laajennusmekanismi, luettelo virallisesti hyväksytyistä lisäosista on pieni, paljon pienempi kuin Pullon laajennusten luettelo.
Kevyempiä kehyksiä, kuten Weppy, käytetään usein RESTful-sovellusliittymien rakentamiseen, ja Weppy toimitetaan tähän tarkoitukseen mukavuuksilla. Laita @service-sisustus reitille, ja palauttamasi tiedot alustetaan automaattisesti valitsemallasi JSON- tai XML-muodossa.
Weppy sisältää muita ominaisuuksia, jotka näyttävät olevan sopusoinnussa suuremman kehyksen kanssa, mutta ne toteutetaan ilman irtotavaraa. Esimerkkejä: Tietojen tarkistusmekanismit, lomakkeiden käsittely, vastausten välimuisti ja käyttäjien vahvistus. Kaikissa näissä tapauksissa Weppy noudattaa "juuri tarpeeksi" -lähestymistapaa. Toimitetut ominaisuudet eivät ole niin täydellisiä kuin saatat löytää Django-kokoisissa puitteissa, mutta kehittäjän ei tarvitse investoida paljon työtä niiden hyödylliseksi tekemiseen, ja niitä voidaan aina laajentaa tosiasiallisesti.
Toinen Weppyssä löydetty ominaisuus, joka liittyy tyypillisesti raskaampaan kehykseen, on kansainvälistymisen tuki. Mallineiden merkkijonot voidaan kääntää sovelluksen mukana toimitettujen kielitiedostojen mukaan, jotka ovat yksinkertaisia Python-sanakirjoja. Kielen valinta voidaan asettaa myös jäsentämällä selainpyyntö (ts. Accept-Language HTTP -otsikko) tai sitomalla käännös tietylle reitille.
Weppyn asiakirjoilla on sama maku kuin itse kehyksellä. Se on puhdas, luettavissa ja kirjoitettu ihmisten kulutettavaksi. Tavallisen "hello world" -sovellusesimerkin lisäksi se sisältää mukavan läpikäynnin opetusohjelman, jonka avulla voit luoda mikroblogijärjestelmän käynnistysprojektina.
Weppyn pitkän aikavälin suunnitelmat sisältävät asynkronoinnin ja pistorasioiden tukemisen matalan tason ensiluokkaisina yksiköinä. Weppyn kehittäjät aikovat ottaa nämä ominaisuudet käyttöön versiossa 2.0 ja vaatia sitten Python 3.7: n tai uudemman kaikille tuleville Weppyn versioille.
| Tuloskortti | Alkuperäinen ominaisuus (20%) | Johto (20%) | Asennus (20%) | Dokumentointi (20%) | Turvallisuus (10%) | Skaalautuvuus (10%) | Kokonaispistemäärä (100%) |
|---|---|---|---|---|---|---|---|
| Pullo 0,12 | 8 | 10 | 10 | 8 | 7 | 7 | 8.6 |
| CherryPy 17.0.0 | 7 | 9 | 9 | 9 | 8 | 8 | 8.4 |
| CubicWeb 3.26.4 | 10 | 8 | 7 | 10 | 9 | 7 | 8.6 |
| Django 2.1 | 10 | 8 | 8 | 10 | 10 | 10 | 9.2 |
| Falcon 1.4.1 | 7 | 10 | 8 | 8 | 7 | 7 | 8.0 |
| Pullo 1.0.2 | 8 | 9 | 8 | 9 | 8 | 8 | 8.4 |
| Pyramidi 1.9.2 | 8 | 8 | 8 | 10 | 9 | 7 | 8.4 |
| Tornado 4.3 | 8 | 9 | 9 | 8 | 8 | 7 | 8.3 |
| Web.py 0,39 | 8 | 8 | 10 | 8 | 9 | 8 | 8.5 |
| Web2py 2.16.1 | 10 | 9 | 7 | 10 | 9 | 8 | 8.9 |
| Weppy 1.2.11 | 10 | 8 | 9 | 9 | 10 | 9 | 9.1 |
| Wheezy.web 0.1.485 | 9 | 9 | 8 | 8 | 8 | 8 | 8.4 |
| Zope2 2.13.24 | 10 | 8 | 7 | 9 | 9 | 9 | 8.6 |
