PEP 594 and cgitb module

Hello there.

I know I am too late for the party, but us mere users don’t normally sit on python mailing lists just to ensure their favorite module was not chopped off – simply because, frankly, this is not something to expect from Python, which was fairly big on backward compatibility.

So speaking of Lib/, which despite the name is mostly used to get extended backtrace for bespoke console scripts and the like – I wonder if there is a way to somehow revive it, may be under a different name, and keep in the standard library?

Looking at the diff between 3.8 and 3.11 – the time when the original PEP 594 was created – I can’t say there was too much change in the code, and most certainly none of it was related to the text mode part, so “Over the years, certain modules have become a heavy burden upon python-dev to maintain” sounds like a bit of an overstatement here.

Besides, whoever wrote “Times have changed. With the introduction of PyPI (née Cheeseshop) …” has clearly never found themeselves locked in a mostly offline datacentre room with an ancient Solaris system that needs some quick maintenance (*), so all you get is whatever comes with “batteries included”, or having to go though an insanely long approval process in a govt org where basically anything that does not come with an approved software package would involve so much bureaucracy that everyone would think twice before even trying to engage in that.

(*) and before you dismiss this as totally irrelevant, think that it could be a system managing your block power or mail delivery system

Fortunately the file we speak of is not too big, so it is not too hard to maintain it as an “external battery”, especially if we speak of only the console traceback part – but I wonder if it can stay alive in some form in the standard repository for the reasons mentioned above.

diff --git a/Lib/ b/Lib/
index 4f81271be3..8ce0e833a9 100644
--- a/Lib/
+++ b/Lib/
@@ -31,6 +31,11 @@
 import time
 import tokenize
 import traceback
+import warnings
+from html import escape as html_escape
+warnings._deprecated(__name__, remove=(3, 13))
 def reset():
     """Return a string that resets the CGI and browser to a known state."""
@@ -105,10 +110,16 @@ def html(einfo, context=5):
         etype = etype.__name__
     pyver = 'Python ' + sys.version.split()[0] + ': ' + sys.executable
     date = time.ctime(time.time())
-    head = '<body bgcolor="#f0f0f8">' + pydoc.html.heading(
-        '<big><big>%s</big></big>' %
-        strong(pydoc.html.escape(str(etype))),
-        '#ffffff', '#6622aa', pyver + '<br>' + date) + '''
+    head = f'''
+<body bgcolor="#f0f0f8">
+<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="heading">
+<tr bgcolor="#6622aa">
+<td valign=bottom>&nbsp;<br>
+<font color="#ffffff" face="helvetica, arial">&nbsp;<br>
+<td align=right valign=bottom>
+<font color="#ffffff" face="helvetica, arial">{pyver}<br>{date}</font></td>
 <p>A problem occurred in a Python script.  Here is the sequence of
 function calls leading up to the error, in the order they occurred.</p>'''
@@ -181,8 +192,8 @@ def reader(lnum=[lnum]):
 <!-- The above is a description of an error in a Python program, formatted
-     for a Web browser because the 'cgitb' module was enabled.  In case you
-     are not reading this in a Web browser, here is the original traceback:
+     for a web browser because the 'cgitb' module was enabled.  In case you
+     are not reading this in a web browser, here is the original traceback:

Hello, the backwards compatibility policy is defined in PEP 387:

It requires warnings for at least two feature releases and cgitb has done so since 3.11: DeprecationWarning: 'cgitb' is deprecated and slated for removal in Python 3.13
  import cgitb

I’m curious, did you not see this warning? I strongly recommend turning on and paying attention to deprecation warnings, there’s usually quite a bit deprecated in each release (not always as big as removed modules), and subsequently removed.

There are community packages of cgitb at legacy-cgi · PyPI and standard-cgitb · PyPI but if you don’t have PyPI access, copying and vendoring the file is the best course of action, especially, as you say, it’s not a big file.


Thanks for reading this and appreciate the suggestions, although I don’t think they are quite to the point.

To address your question – let’s imagine an average Ubuntu Linux user, who upgrades from one LTS release to another, let us say, Ubuntu 20.04 LTS (python 3.8), Ubuntu 22.04 LTS (python 3.10), Ubuntu 24.04 LTS (python 3.12).

24.04 release date is 25th April 2024, so yes, by the time one sees the depreciation message, it is long stamped, sealed and gone.

Many thanks for your time anyway, I hope we both learned something new today