On 2022-10-25 18:05, Thomas Hochstein wrote:

Hermann Riemann schrieb:

...

In

https://docs.python.org/3.11/whatsnew/3.11.html

steht unter PEP 594 led to the deprecations of the following modules slated for removal in Python 3.13:

cgi und cgitb

Ich benutze die beiden Funktionen meist um Daten, die in html zwischen <form> und </form> eingegeben werden, auszuwerten.

Auf was müsste ich umstellen?

Im "PEP 594" stehen die Gründe für die vorgesehene Entfernung der dort genannten Module und vorgeschlagene Ersatzlösungen. Für cgi und cgitb gibt es keinen unmittelbaren Ersatz. Vielmehr heißt es dazu: [1]

| cgi | | The cgi module is a support module for Common Gateway Interface (CGI) | scripts. CGI is deemed as inefficient because every incoming request is | handled in a new process.

Bei diesem Argument muss ich immer schmunzeln. Wie lange dauert ein fork() und exec() unter Linux? Gut, wenn man einen Interpreter wie Python verwendet und dann noch ein paar Module lädt (cgi, psycopg2, ...) ist man bald bei 100 oder 200 Millisekunden. Aber ich habe schon Java-CMS gesehen, die länger für eine Seite gebraucht haben - und die haben für *jede* Seite so lang gebraucht, nicht nur für das Resultat eines POST-Requests. Bei den meisten Websites ist vollkommen egal, ob ein Webformular in 10, 100 oder 1000 Millisekunden verarbeitet wird.

| The cgitb module is not used by any major Python web framework (Django, | Pyramid, Plone, Flask, CherryPy, or Bottle).

Da sind die praktikablen Ersatzmöglichkeiten versteckt. "Major Python web framework" klingt erst mal etwas abschreckend, aber erstens bezieht sich das "major" wohl eher auf die Verbreitung als die Größe und zweitens muss man ja nicht gleich den ganzen Funktionsumfang nützen. Von den genannten habe ich Django und Flask genützt und außerdem FastAPI. Django[1] kann (fast) alles (Request Routing, Parameter Parsing, Form Handling, Datenbankzugriffe via ORM, Templates, ...), ist aber ziemlich "opinionated". Wenn man es so verwendet, wie die Django-Macher es sich vorstellen, funktioniert es gut. Wenn man davon abweichen will oder muss (in unserem Fall: Weil das Datenmodell vorgegeben und, äh, etwas speziell war), wird es schmerzhaft. Außerdem hat man einiges zu lernen. Flask[2] ist hübsch minimalistisch. Tut out of the box nicht viel mehr als Request Routing und Parameter Parsing, und das hat man schnell gelernt. Bei Bedarf gibt es alle möglichen Extensions. Wäre meine Empfehlung für jemanden, der eine Handvoll CGI-Scripts ablösen will. FastAPI[3] ist wie der Name sagt, eher auf APIs zugeschnitten (insbesondere solche, die JSON konsumieren und produzieren). Kann natürlich auch für beliebige Web-Applikationen verwendet werden, aber man merkt, dass das nicht der intendierte Einsatzzweck ist. Und für Leute, die nicht gerne JavaScript fürs Frontend schreiben aber auf eine gewisse Mikro-Interaktivität nicht verzichten wollen, möchte ich noch kurz Werbung für HTMX[4] machen. hp [1] https://www.djangoproject.com/ [2] https://flask.palletsprojects.com/en/2.2.x/ [3] https://fastapi.tiangolo.com/ [4] https://htmx.org/

Am 26.10.22 um 09:22 schrieb Hartmut Goebel:

Das Argument finde ich ziemlich schwachen, denn es gibt genügend Anwendungsfälle, bei denen CGI völlig ausreichend ist. Beispielsweise wenn man eine Website betreibt, bei der 5-ml im Jahr jemand das Kontaktformular benutzt.

Und für die paar Leute mit diesem Use-Case möchte man das eben nicht weiter supporten. Ich verstehe das schon. Nebenbei: das Parsen eines Formulars, das per CGI 'reinkommt, ist auch ziemlich fix herunter getippt. Gruß, Thomas -- I have seen things you lusers would not believe. I've seen Sun monitors on fire off the side of the multimedia lab. I've seen NTU lights glitter in the dark near the Mail Gate. All these things will be lost in time, like the root partition last week.

It is hanging to see you express from the heart and clearness on this key subject can be truly taken note. https://www.bangaloreescortindia.co.in i like a ton of your post.