I've been able to reproduce this outside of mod_wsgi. It appears to be an issue with the Python 3.12 in Ubuntu 24.04 when it's combined with sub-interpreters. I have a test program,
https://www.cs.toronto.edu/~cks/vendors/ubuntu2404-python/subinterp-list-bug.c which (if I'm using Py_NewInterpreter() properly) shows that on Ubuntu 24.04, list.__str__ gets set in the sub-interpreter. On Fedora 40, which has Python 3.12.8, this doesn't happen, so this isn't a Python 3.12 issue in general. Since we run only a single (Django) web application on this machine, I think that using 'WSGIApplicationGroup %{GLOBAL}' is a viable workaround (assuming I understand it correctly from the documentation), although we'll need to leave ourselves a big comment in the configuration and I believe it wouldn't be safe with multiple Django applications. Assuming that I want to trust Ubuntu 24.04 at all after this. Thank you, everyone. - cks > An update: adding 'WSGIApplicationGroup %{GLOBAL}' to my mod_wsgi > settings, which I understand forces my test WSGI pseudo-application > to run in the context of the first Python interpreter created and not a > sub-interpreter, makes the issue go away: > list.__str__ is <slot wrapper '__str__' of 'object' objects> > > I'm going to see if I can hack the example 'embedding Python' C program > to use a sub-interpreter and test the behaviour there. > > - cks > > > We're definitely using the system packages for mod_wsgi (and for > > Python). Ubuntu 24.04's Python is '3.12.3', and I've used lsof to verify > > that the relevant Apache process has the right Python shared library > > loaded; it is using '/usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0' > > (Ubuntu package 'libpython3.12t64', also 3.12.3), and is also using the > > system mod_wsgi, '/usr/lib/apache2/modules/mod_wsgi.so-3.12'. > > > > (Ubuntu 24.04's Apache is '2.4.58', possibly plus Ubuntu patches.) > > > > As GODJonez notes, 'list' doesn't normally have a __str__ method; > > instead it usually comes from 'object'. The Ubuntu 24.04 normal python3 > > binary behaves properly, with 'list.__str__' reporting: > > <slot wrapper '__str__' of 'object' objects> > > > > Within the mod_wsgi environment, 'list.__str__' is: > > <slot wrapper '__str__' of 'list' objects> > > > > (basically as expected), which as GODJonez notes explains the problem. > > > > I built the extremely simple 'embedding Python in another application' > > example from https://docs.python.org/3/extending/embedding.html and > > linked it against the same libpython3.12.so.1.0 just to check, and it > > reports that list.__str__ comes from 'object' as expected. > > > > - cks > > > > > What version of Python is Ubuntu using? > > > > > > Are you definitely using system package for mod_wsgi, or have you per > > > chance used pip to install mod_wsgi package and integrated that into your > > > Apache instead? > > > > > > Are you using a Python virtual environment? > > > > > > FWIW, I don't see issues on macOS using mod_wsgi-express and Python 3.12. > > > > > > Graham > > > > > > > On 15 Jan 2025, at 3:46 am, Chris Siebenmann > <cks.modwsgi...@cs.toronto.edu> wrote: > > > > > > > > I've encountered what I can only describe as an extremely weird problem > > > > with method resolution order that happens only in mod_wsgi on Ubuntu > > > > 24.04, using the Ubuntu 24.04 version of mod_wsgi (with their Apache and > > > > Python 3), which appears to be an unpatched 5.0.0. The specific problem > > > > is > > > > that if you have a class that inherits from 'list,<something else>', and > > > > the second class normally supplies a __str__ method, under mod_wsgi you > > > > get list.__str__ instead. This first manifested in a Django > > > > application[*] > > > > but the minimal reproduction for us is a wsgi.py application that has: > > > > > > > > import sys > > > > > > > > class barney: > > > > def render(self): > > > > return "render() in barney" > > > > __str__ = render > > > > > > > > class fred(list, barney): > > > > pass > > > > > > > > print("fred.__str__ is", fred.__str__, file=sys.stderr) > > > > > > > > (and then the documentation example 'hello world' WSGI application() > > > > function so that mod_wsgi is happy to start this, and will produce > > > > output so that I know the whole thing is working correctly) > > > > > > > > On Ubuntu 24.04's mod_wsgi, this will report on startup: > > > > fred.__str__ is <slot wrapper '__str__' of 'list' objects> > > > > > > > > In any other environment, including Ubuntu's mod_wsgi on 20.04 and 22.04 > > > > (which use earlier versions of mod_wsgi), this reports what we expect: > > > > fred.__str__ is <function barney.render at 0x782909bff2e0> > > > > > > > > (Other tests show that the 'barney' class is one of fred's parents and > > > > other attributes are being inherited from it, even though its __str__ > > > > isn't being used.) > > > > > > > > The actual fred.__mro__ appears to be the same between environments, > > > > listing 'fred', 'list', 'barney', and 'object' in that order. > > > > > > > > I'm running this test wsgi.py with a very simple WSGI configuration > > > > in Apache: > > > > WSGIScriptAlias /accounts /<test location>/wsgi.py > > > > WSGIDaemonProcess accounts user=<...> group=<...> > > > > WSGIProcessGroup accounts > > > > > > > > Does anyone have any idea what might be going on and either how to fix > > > > it or how to debug it? > > > > > > > > Thanks in advance. Please let me know if I can provide more information > > > > that would be helpful. > > > > > > > > - cks > > > > [*: The specific symptom we saw was that empty > > > > django.form.util.ErrorList > > > > instances using default rendering in templates would render as > > > > '[]' instead of blank. This was traced to them using list.__str__ > > > > for rendering instead of their custom rendering, which is set up in > > > > the same way that 'class barney' is in this example. > > > > ] -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/modwsgi/522650.1736899932%40apps0.cs.toronto.edu.
