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/20250114221035.3C77160276%40apps0.cs.toronto.edu.
