Py4Web

[ahorn6]

Hallo allen und ein gesundes Jahr 2021

Ich hatte mich einst hier angemeldet, um etwas über Web2Py zu erfahren; das Gezänk um Web2Py und seine Abwertung hier im Forum hatten mich abgestoßen, konnten mich aber nicht davon abbringen, es mir nach meinen Wünschen zu konfigurieren und mit Gewinn zu nutzen.

Nun gibt es vom selben Team eine Weiterentwicklung:

Py4Web

Da ich unter diesem Stichwort hier keinen Eintrag fand, möchte ich dazu zitieren:

PY4WEB can be seen as a competitor of other frameworks like Django or Flask, and it can indeed serve the same purpose. Yet PY4WEB aims to provide a larger feature set out of the box and reduce the development time of new apps.

Gruß
Erich

[noisefloor]

Hallo,

aha... mal sehen, wie sich das entwickelt.

IMHO ist der Markt für Webframeworks ziemlich besetzt. Django und Flask sind die Platzhirsche, dann kommt länger nichts, Tornado und CherryPy haben auch einen akzeptabel große Nutzergemeinde.

Natürlich ist immer Platz für neues, wenn das Neue was besser kann, wie z.B. das aktuell ziemlich populäre FastAPI. Ob das nur ein temporärer Hype ist oder längerfristig bleiben wird, wird sich dann zeigen.

Basierend auf der Doku von Py4Web ist da jedenfalls für mich so überhaupt nichts, was mich dazu motivieren würde, dass statt Django zu nutzen.

Gruß, noisefloor

[ahorn6]

Hallo noisefloor

Dein Nick und Dein Loge lassen mich vermuten, dass Du mit Akustik vertraut bist. Um Dir zu verdeutlichen, wozu ich Web2Py verwende, möchte ich Dir ein Beispiel zeigen:

https://meyerich.pythonanywhere.com/Hermode

Es geht mir darum, Artikel schreiben zu können, in denen ich außer Text auch Graphik und Audio mitteilen kann und dass ganze strukturiert mit einem Inhaltsverzeichnis.

Ich habe bewusst auf einen allgemeinen Zugang zu meiner Seite verzichtet, da ich mich nicht mit Trolls herumplagen will; für meine Zwecke hat sich mein Web2Py hervorragen bewährt.

Wie ich zu Web2Py kam:

Ich hatte in den Nullerjahren eine LinuxUserGruppe geleitet und dazu eine Internetseite in Drupal gepflegt. Mich hatte damals gestört, dass die Frameworks alle so aufgesetzt waren, dass die damit erstellten Seiten immer für alle zugänglich waren und der Zugang nicht auf eine spezielle Gruppe eingeschränkt werden konnte. So war ich dann auf Web2Py gestoßen. Es ist mir schon klar, dass Webseiten im Allgemeinen dazu aufgesetzt werden, um etwas in die Welt zu posaunen. Es dürfte klar sein, dass ich ein etwas anderes Ziel verfolge.

Gruß
Erich

[noisefloor]

Hallo,

Dein Nick und Dein Loge lassen mich vermuten, dass Du mit Akustik vertraut bist.

Nein, überhaupt nicht. Falsche Assoziation

Mich hatte damals gestört, dass die Frameworks alle so aufgesetzt waren, dass die damit erstellten Seiten immer für alle zugänglich waren und der Zugang nicht auf eine spezielle Gruppe eingeschränkt werden konnte.

Ich weiß ja nicht, was ihr das so getrieben habt - aber Zugangskontrolle gibt es schon ewig lange. Je nach dem, wie wer wo was liefert, musst du das halt über den Webserver (wie z.B. Apache) umsetzen.

Das DAS der Grund für Web2Py war ist schon ein bisschen... schräg. Django hat z.B. ein sehr umfangreiches Authentifizierungs-Framework an Bord, was Benutzerrechte und Benutzergruppen kennt. Da Authentifizierung und Nutzerverwaltung nun mal nichts exotisches ist, gehe ich mal davon aus, dass andere Frameworks das auch können.

Gruß, noisefloor

[DasIch]

Django ist nicht nur Django selbst. Zu Django gehört auch ein Ökosystem an django apps mit denen man das Framework erweitern kann, eine sehr große Community bzw. mehrere mit Konferenzen, lokalen User Gruppen usw. Jeder Python Entwickler der Python und Web macht kennt und hat sicherlich Django mindestens mal ausprobiert.

Mittel- bis langfristig kann man in ein Framework nicht soviel investieren wie die Django Community es macht, deswegen ist Konkurrenz nahezu unmöglich es sei den man ist irgendwie besser auf eine Weise die Django nicht schnell oder überhaupt replizieren kann. Flask schafft dass für kleinere Anwendungen und APIs. FastAPI schafft dass für gute async Unterstützung. Web2py hat sowas nicht und hat es nie geschafft Momentum aufzubauen. Ich sehe nicht wieso "faster and slicker" als web2py dies ändern sollte.

Wer wirklich schneller sein möchte nimmt einfach JS, wer es noch schneller haben möchte geht zu go und wenn einem dass noch nicht genug ist bleibt rust. py4web kann damit fundamental nicht konkurrieren. Django und Flask sind auch selbst schon ziemlich "slick", das löst kein Problem.

[ahorn6]

Hallo noisefloor,

nett. dass Du mir geantwortet hast; aber ein bisschen historisches Interesse wäre schon hilfreich, ehe Du so formulierst:

Das DAS der Grund für Web2Py war ist schon ein bisschen... schräg. Django hat z.B. ein sehr umfangreiches Authentifizierungs-Framework an Bord, was Benutzerrechte und Benutzergruppen kennt. Da Authentifizierung und Nutzerverwaltung nun mal nichts exotisches ist, gehe ich mal davon aus, dass andere Frameworks das auch können.

Ich sprach von den Nullerjahren, vielleicht hätte ich statt Drupal Drupal-4 schreiben sollen. Ich hatte mich damals an die Drupal-Community gewandt mit der Bitte, den Zugang zur Seite beschränken zu können; damals wurde mir Drupal-7 avisiert; darauf wollte ich nicht warten.

Über Django finde ich im Netz folgende Daten:

Erscheinungsjahr 21. Juli 2005
Initial release May 2007

und Du bist Dir sicher, Authentifizierung war schon damals nichts exotisches usw.

Dass Django heute ein sehr umfangreiches Authentifizierungs-Framwork an Bord hat, ist doch ein Hinweis, der an der Sache - historisch gesehen - vorbeigeht. In meinem Büchschrank finde ich aus den Nullerjahren Bücher über Plone, Djangio, TurboGears, Pylons, Drupal.

Ich wollte nur verständlich machen, dass man auch einen anderen begründeten Blick auf ein CMS haben kann und dass ich hier durch einen unangemessenen Ton verprellt wurde. Zu diesen schrägen Melodien rechne ich auch Deinen Satz:

Das DAS der Grund für Web2Py war ist schon ein bisschen... schräg.

Gruß
Erich

[sparrow]

@ahorn6: Du redest hier von einem CMS. Das verwirrt mich. Weder Web2Py noch Py4Web sind ja Conntent Managenemnt Systeme. Es sind Webframeworks. Ansonsten kann ich noisefloor verstehen - Benutzerverwaltung und -authentifizierung ist nun nichts Neues und sicher keine Technik die erste nach den 00er Jahren eingeführt wurde. Und ja, Django konnte das bereits vor 15 Jahren. Kann man in deren Quelltext nachvollziehen. Und aus eigener Erfahrung kann ich sagen, dass ich mich schon vor den 00er Jahren - also im alten Jahrtausend - auf Internetseiten anmelden musste

So, aber mal Butter bei die Fische, wie wir hier im Norden sagen: Authentifizierung ist nicht der neue heiße Scheiß sondern eher die Basics für ein Webframework. Django und Flask sind etabliert. Was macht für dich Py4Web besser? Und was macht Py4Web besser als Web2Py, das bereits keinen große Benutzerbasis (im Gegensatz zu Django oder Flask) aquirieren konnte?

Edit: Das Internet sagt übrigens, Drupal führte mit der Version 2 "Lokalisierungen und Berechtigungssystem" ein. Das klingt für mich sehr nach Zugangsbeschränkung . Und wenn man seine Seite ganz Beschränken möchte, dann macht das sowieso nicht die Webapplikation, dann löst man das über den Werbserver.

[ahorn6]

Hallo DasIch!

Etwas mehr Gelassenheit wäre schön!

Wenn ich einen Artikel schreiben möchte, der nicht in ein Buch passt, weil ich über Musikalisches schreiben möchte, wo ich auch Tonbeispiele hörbar machen möchte, dann ist ein CMS das geeignete Mittel. Und wenn ich so einen Artikel nicht in die Welt posaunen will, sondern nur einem beschränkten Kreis von Interessierten zugänglich machen will, dann brauche ich ein kleines System mit Zugangsbeschränkung. Und wenn der Artikel strukturiert sein soll und man nicht ellenlang scolen soll, dann braucht man ein schnell zugängiges Inhaltsverzeichnis: das leistet für mich Web2Py.

Um anschaulich zu bleiben, hier noch eine kleine Seite von mir:
https://meyerich.pythonanywhere.com/Mathematik

Vielleicht weitet sich nun der Blick auf einen Aspekt, wozu ein CMS auch brauchbar sein kann.

Gruß
Erich

[nezzcarth]

Mich hatte damals gestört, dass die Frameworks alle so aufgesetzt waren, dass die damit erstellten Seiten immer für alle zugänglich waren und der Zugang nicht auf eine spezielle Gruppe eingeschränkt werden konnte.

Wenn es nur um die Authentifizierung geht, die ist bereits in den ersten HTTP-Spezifikationen aus der Mitte der 90er enthalten (z. B. RFC 1945 von 1996) und wird auch von gängigen Webservern aus der Zeit (z. B Apache 1.3.1) bereits unterstützt. Einen einfachen Zugangsschutz (User darf eine Seite sehen oder nicht) konnte man also "schon immer" gewährleisten. Ausgefeilte Berechtigungssystem sind vielleicht etwas anders. Da gab es aber mit Zope ebenfalls seit Ende der 90er mindestens ein Webframework, das das soweit mir bekannt ist konnte. Gerade in Intranets (im Enterprisebereich) ist diese Anforderung auch nicht ungewöhnlich. Ich glaube, die Diskussion wird auch etwas erschwert, weil teilweise von einen CMS - Drupal - die Rede ist, teilweise jedoch von einem Webframework - web2py. Das sollte man schon auseinanderhalten. Eine Rechteverwaltung ist zum Beispiel nichts, was ich von einem Webframework zwangsweise erwarten würde, von einem (guten) CMS jedoch schon eher; bei Django gehört es halt dazu, bei anderen Systemen nicht. Ich kann mir vorstellen, dass es zu der Zeit vielleicht nicht leicht war, schnell die Optionen zu finden, die es gegen hätte und wenn du mit web2py zufrieden bist, ist das doch gut.

[ahorn6]

@ sparrow:
notwendig vs. hinreichend

Es ging nicht darum, dass man sich anmelden kann, sondern dass man nicht angemeldet keinen Zugang hat auch keinen bedingten, wie es ja in diesem Forum der Fall ist; dieses wird ja im Allgemeinen intendiert; aber ich wollte das nicht, da mir nur an einer internen Kommunikation lag.

[__deets__]

War mit ZOPE/PLONE auch damals alles schon da. ZOPES hierarchisches Rechtemodell haette dir problemlos erlaubt, auf oberster Ebene nur angemeldeten Benutzern Zugriff zu gestatten. Alles, was an Inhalt darunter lag, waere ebenfalls geschuetzt gewesen.

Aber solche historischen Betrachtungen sind muessig - das web2py dir gepasst hat, ist gut fuer dich. Es aendert nichts daran, dass web2py keine relevante Rolle in der Python-Webwelt spielt, und sein Nachfolger wird aus Gruenden, die DasIch schon sehr gut (und ruhig...) dargelegt, das gleiche Schicksal ereilen. In 5 Jahren wird immer noch Django der Platzhirsch sein, und Flask und Tornado spielen irgendwo auf hinteren Plaetzen. Alles was dann kommt (auch zB das an sich sehr nette bottle) ist Rauschen.

[__blackjack__]

@__deets__: Grundsätzlich d'accord, aber in 5 Jahren könnte auch ein neues Rahmenwerk irgendwo zwischen Django und dem Rest auftauchen, was irgend etwas anders, neuer, hipper macht, und dann entweder auch wieder an Bedeutung verlieren oder gewinnen. Zum Beispiel irgend etwas das auf ``async`` setzt und/oder irgendwelche Syntaxneuerungen die in kommenden Python-Versionen gehyped werden.

[__deets__]

async ist doch schon Tornado. Vielleicht gewinnt das dadurch, das mag sein. Generell denke ich ist Python im Web eher nicht auf dem aufsteigenden Ast - da spielen mit Node und Go mehr und mehr andere Sprachen die vorderen Geigen. Finde ich persoenlich auch nicht schlimm. Web habe ich hinter mir

[kbr]

Jedes neue Framework, wie z.B. Starlette, muß irgendwie "hip" daherkommen und irgendetwas besser machen um Aufmerksamkeit zu erlangen. Und genügend fehlerfrei sein, um auch in Production einsetzbar zu sein. Hier gegen seit langem gepflegte Frameworks anzukommen, ist sicher eine Herausforderung. Wo auch gerade deren hohe Verbreitung das Aufdecken und beseitigen von Fehlern begünstigt.

Wenn ich eine Webanwendung mache, ist mir ein stabiles Framework wichtiger als der neueste Hype. Für Anwender mit dieser Philosophie sehe ich Python gut aufgestellt.

[__blackjack__]

@__deets__: Ich meinte mit ``async`` das Schlüsselwort, also ein Webrahmenwerk das auf ``async``/`await`` setzt und vielleicht auf ASGI statt WSGI.

[DasIch]

@__blackjack__: Gibt es schon mit starlette, fastapi und co. die schon erwähnt wurden. Die konkurrieren aber im wesentlichen mit Flask und nicht mit Django. Django selbst hat aber auch schon rudimentären async support, der wird sicherlich auch nur besser werden. Insofern würde ich einem Django-aber-async Framework keine großen Chancen einräumen, es sei den die Django Leute kriegen es nicht auf die Reihe viel Fortschritt zu machen.

Ich hab aber den Eindruck dass der aktuelle Trend sowieso ist alles was "frontend" ist in JS zu machen und "frontend" schliesst mitunter auch Sachen ein die auf dem Server laufen und da React serverseitig rendern. Sprachen die nicht JS sind nutzen HTTP nur noch als RPC und nicht um Webseiten auszuliefern. Dementsprechend verliert auch Django (und ähnliche Frameworks wie RoR) an Relevanz.

Wobei natürlich sich immer die Frage stellt wieviel der Hype mit der Realität zu tun hat aber zumindest bei uns trifft dass schon zu.

[noisefloor]

Hallo,

...aber zumindest bei uns trifft dass schon zu.

Gut zu wissen - ich dachte, Zalando nutzt auch Web2Py, weil Zalando ja auch einen Login für die Kunden braucht *SCNR*

Im Ernst: Die Frage, die wahrscheinlich keiner hier beantworten kann, ist, wie sich da, was die "großen" machen, also nicht nur die ganz großen wie Amazon, Google, Facebook & Co, sondern auch Zalando und ähnlich Sachen in der Liga, auf die mittelgroßen und kleineren Webseiten auswirkt bzw. da rein reflektiert. Sehr viele Webseiten bzw. Webangebote haben ja nicht X Tausend oder X Zehntausend Request pro Sekunden. Und ich denke, dass sich da die etablierten Sachen wie Django oder RoR oder die ganze Sachen, die es in PHP gibt, noch passable lange halten werden. Sicher bin ich mir das nur, dass Py4Web da nicht mit spielen wird.

Gruß, noisefloor

[__blackjack__]

In dem Zusammenhang ein Klassiker: You Are Not Google.

[naheliegend]

async ist doch schon Tornado. Vielleicht gewinnt das dadurch, das mag sein. Generell denke ich ist Python im Web eher nicht auf dem aufsteigenden Ast - da spielen mit Node und Go mehr und mehr andere Sprachen die vorderen Geigen. Finde ich persoenlich auch nicht schlimm. Web habe ich hinter mir

Warum ist Node und Go besser als Python?

[__deets__]

Besser ist relativ. Go ist zb deutlich performanter, und Node ist wegen der Nähe und Wiederverwendbarkeit von JS in Front- und backend beliebt. Wenn du Programmierer hast, die in zwei statt einer Sprache gut sein müssen, macht das einen Unterschied.