classification
Title: Message methods delegated via __getattr__ inaccessible using super().
Type: behavior Stage: resolved
Components: email Versions: Python 3.5, Python 3.4
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, Brian.Jones, barry, r.david.murray
Priority: normal Keywords: patch

Created on 2012-03-13 22:12 by Brian.Jones, last changed 2014-09-20 21:29 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
msg_api_subclass_bug_test.patch Brian.Jones, 2012-03-13 22:12 Adds a unit test to trigger brokenness in how super() is being used to call parent-delegated methods.
Messages (3)
msg155679 - (view) Author: Brian Jones (Brian.Jones) * Date: 2012-03-13 22:12
In email6, the message.Message class tries to delegate calls to methods not defined in Message to message._HeaderList. However, delegating in this way makes the methods inaccessible when accessing them through a call to super(). This comes into play in the http.HTTPMessage class, which attempts to call the _HeaderList 'get' method as 'super().get()'. An AttributeError is raised in this case, because super is only examining the class, and not the instance, and isn't executing __getattr__ to get at methods defined in _HeaderList methods. 

I've attached a patch that only patches the appropriate test module to add a test to prove the failure. The fix involves a bit more complexity, and I've had some trouble getting my brain to not reject the kind of conflation of concepts and overlapping of responsibility that needs to take place to implement the ideas I was able to come up with. I'm happy to help implement a sane solution if anyone has other ideas. 

A couple of ideas that came up (at the PyCon sprints) were: 

1.  Make _HeaderList *not* extend 'list', and then have Message inherit from _HeaderList. However, that means basically reimplementing all of the methods in the 'list' interface inside of _HeaderList, and by extension, Message becomes something of a 'list' object for the purpose of header manipulation, but not for anything else (like, say, payload). 

2. Just get rid of _HeaderList and put it all inside of Message. See item 1 for issues with this idea. 

3. Expose a public 'headers' attribute, which opens a lot of doors in terms of design flexibility, elegance, and cleanliness, but changes the API. 

4. Create a base class that defines the non-list-specific interface for _HeaderList. _HeaderList would then inherit from this class, adding the list-specific methods on top, and Message would inherit it and only override non-list-specific methods. This could have some benefits in terms of testing, but arguably it muddies the waters for those maintaining/extending the _HeaderList or Message code.

Other ideas? Also let me know if I've done something silly in writing the test to trigger the problem.
msg222186 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-03 14:26
@David I believe this is one for your TODO list.
msg227179 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-09-20 21:29
_Headerlist never made it into the committed code.  Subclassing Message works fine in both the mainline email code and the provisional extensions.
History
Date User Action Args
2014-09-20 21:29:37r.david.murraysetstatus: open -> closed
resolution: out of date
messages: + msg227179

stage: resolved
2014-07-03 14:26:10BreamoreBoysetversions: + Python 3.4, Python 3.5, - Python 3.3
nosy: + barry, BreamoreBoy

messages: + msg222186

components: + email, - Library (Lib)
type: behavior
2012-03-13 22:12:52Brian.Jonescreate