= Python2.7 =

https://twitter.com/securitytrails/status/1252658491757600768?s=20

https://pythoninsider.blogspot.com/2020/04/python-2718-last-release-of-python-2.html
{{{
Python 2.7.18 is the last Python 2.7
release and therefore the last Python 2 release. It's time for the CPython
community to say a fond but firm farewell to Python 2.
}}}

http://bugs.python.org/issue9631

This is probably best explained by the patch I applied to revert to 2.6.x behavior, which fixed the compile problem for me:
{{{
--- Python-2.7.1/Lib/site.py    2010-10-12 18:53:51.000000000 -0400
+++ Python-2.7.1/Lib/site.py.addbuilddir-revert 2011-04-16 23:03:47.000000000 -0400
@@ -122,7 +122,7 @@
     s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
     if hasattr(sys, 'gettotalrefcount'):
         s += '-pydebug'
-    s = os.path.join(os.path.dirname(sys.path.pop()), s)
+    s = os.path.join(os.path.dirname(sys.path[-1]), s)
     sys.path.append(s)
}}}
Obviously I imagine there was a reason why this change was made, so the above patch is probably not an appropriate universal fix.  I don't know anything about the original reasoning, but this change does seem to work for me on CentOS 5.5 now.

-----
I also had an ImportError on _struct module during 'make install' when building 2.7.3 from source configured with --enable-shared. My solution, which *seems* to have worked, is simple:
{{{
   $ make -i install
   $ make install
}}}
My guess is that the part of the 'make install' that copies _struct.so into the correct place occurs AFTER a part of the 'make install' that tries to use it. If you tell make to ignore errors and carry on (-i), it then completes the installation, copies _struct.so (and everything else) into their correct places, and you can then do another make install without any errors!