Normally, list does not define __str__ method, so the MRO resolves to the second subclass. Why does a list have __str__ in this case is a mystery to me.
On Tue, Jan 14, 2025, 22:27 Chris Siebenmann <[email protected]> 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/modwsgi/20250114164612.4605560276%40apps0.cs.toronto.edu > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/modwsgi/CAPnmswhqaf7FrtQWoErF564ENDNmxtWGPdJTDbroVg5bOrH9Ag%40mail.gmail.com.
