This might be better as: return repr(self.__dict__) That way, we get field names, and the hard work is done for us.
Can you put the comment on the line before this? One "#" and put this in sentence case, end with period.
If we're going to ship this, the docs probably shouldn't talk about how this may be the wrong place for it. We shouldn't add this if we're not sure about it. I'm unsure as to whether this is the right move. I'm thinking it's not. Rather, if we absolutely need this information, we should just never get rid of it in the first place, and if it makes patch unhappy, then let's have functionality that normalizes a diff before passing it to patch. That can be subclassed in the DiffParser.
Move raw patch logic out of view and into diffparser
Review Request #598 — Created Oct. 20, 2008 and discarded
|Review Board SVN (deprecated)|
This is mostly to generate discussion. I'd like to implement my own raw patch mechanism (I need to re-create some of the information that was lost during the diff parse stage). I've moved code from the rawview into the diff parser so that I can implement my own logic in a subclass of diffparser. Moving the logic out of the view also means that the raw patch can be exposed in other places, e.g. we could expose the diff in an email (NOTE if this was done would need to be configurable so that normal users don't suffer the overhead of generating raw patches, e.g. lazy/deferred evaluation or a config option). A repr() implementation for File also snuck into this change as I found this useful for debugging.
tested with svn (normal raw diff) and with a subclassed custom diffparser