cgi cgitb Ersatz für Python 3.13

[Hermann Riemann]

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?

[Thomas Hochstein]

Hermann Riemann schrieb:

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. PEP 206 considers the module as:
|
| "[…] designed poorly and are now near-impossible to fix (cgi) […]"

Das ist der Grund für die vorgesehene Entfernung.

| Replacements for the various parts of cgi which are not directly related
| to executing code are:
|
| * parse with urllib.parse.parse_qs (parse is just a wrapper)
| * parse_header with email.message.Message (see example below)
| * parse_multipart with email.message.Message (same MIME RFCs)
| * FieldStorage/MiniFieldStorage has no direct replacement, but can
| * typically be replaced by using multipart (for POST and PUT requests)
| or urllib.parse.parse_qsl (for GET and HEAD requests)
| * valid_boundary (undocumented) with re.compile("^[ -~]{0,200}[!-~]$")
|
| As an explicit example of how close parse_header and
| email.message.Message are:
|
| >>> from cgi import parse_header
| >>> from email.message import Message
| >>> parse_header(h)
| ('application/json', {'charset': 'utf8'})
| >>> m = Message()
| >>> m['content-type'] = h
| >>> m.get_params()
| [('application/json', ''), ('charset', 'utf8')]
| >>> m.get_param('charset')
| 'utf8'
|
|cgitb
|
| The cgitb module is a helper for the cgi module for configurable
| tracebacks.
|
| The cgitb module is not used by any major Python web framework (Django,
| Pyramid, Plone, Flask, CherryPy, or Bottle). Only Paste uses it in an
| optional debugging middleware.

-thh

[1] Webseiten vorlesen ist irgendwie doof.

[Peter J. Holzer]

On 2022-10-25 18:05, Thomas Hochstein <t...@thh.name> 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/

[Hartmut Goebel]

Hallo,

Am 25.10.22 um 20:05 schrieb Thomas Hochstein:

> | 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. PEP 206 considers the module as:
> |
> | "[…] designed poorly and are now near-impossible to fix (cgi) […]"
>
> Das ist der Grund für die vorgesehene Entfernung.

Auch wenn diese ML der falsche Fleck ist, um das zu diskutieren:

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.

(Das Formular für meinen decompyle-Service war ebenfalls in CGI
implementiert. Für die paar Anfragen im Jahr völlig ausreichend.)

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
https://www.goe-con.de/blog/steuerbehoerden-torpetieren-freie-software
Kolumne:
https://www.goe-con.de/hartmut-goebel/cissp-gefluester/2012-01-in-die-cloud-in-die-cloud-aber-wo-soll-die-sein

[Thomas Orgelmacher]

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.

[Massa, Harald Armin]

PEP 206 considers the module as:
> |
> | "[…] designed poorly and are now near-impossible to fix (cgi) […]"

habe grade mal in den Quellcode geschaut, hier zum Klicken:

https://github.com/python/cpython/blob/3.11/Lib/cgitb.py

in den 332 Zeilen des Modules sind diverse Vorgehensweisen, die
üblicherweise als
"so bitte nicht" beschreiben werden.

WENN das Projekt darauf aufbaut ... dann in Python 3.13ff einfach das Modul
aus 3.11 ins Projektverzeichnis kopieren. Und ab dann ist eben der
Projektowner für das Fixen verantwortlich.

Gruß

Harald




On Wed, 26 Oct 2022 at 09:22, Hartmut Goebel <h.go...@goebel-consult.de>
wrote:

> _______________________________________________
> python-de Mailingliste -- pyth...@python.org
> Zur Abmeldung von dieser Mailingliste senden Sie eine Nachricht an
> python-...@python.org
> https://mail.python.org/mailman3/lists/python-de.python.org/
> Mitgliedsadresse: ch...@ghum.de
>


--

GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607

Amtsgericht Stuttgart, HRB 734971
GF: Harald Armin Massa

[imsoniya...@gmail.com]

I just couldn't give your site going before telling you that I really participated in the top quality information you present to your
visitors? https://www.modelescortsindelhi.com/massage-republic-service.html Will be back again every goliath no mentioning a fundamental entryway to pick what is the deal with new posts

[imsoniya...@gmail.com]

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.