On 8/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > The stuff I'm doing can safely be ignored because it's an addition on > top of existing stuff. The reason for this approach is that it's 100% > backwards-compatible and it doesn't fall into the trap of prematurely > limiting options -- if the common case provided by the "default" > contribute_to_class, __set__ and __get__ isn't appropriate, you just > write your own. So you can write your own now and, if it turns out to be > useful to use the convenience methods later, fix it then.
Ah, okay. I had been holding off because I kept expecting it was going to be a cure-all like I kept attempting. It does make a lot of sense to stick to the common case though, and deal with other cases if they ever become common in their own right. I'll get started knocking around some work with FileField and see if I can come up with something that solves some of the problems discussed. I'll definitely look around Trac too though, and see if there are any other concerns that I might be able to address at the same time. On a related note, if (as I expect would the case here) a patch ends up involving multiple tickets, how should that be handled in Trac? Just pick one of the tickets that seems most important and go with that one? These kinds of refactorings are typically done by people with checkin priveleges, so I'm not sure how a patch like this should be submitted. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
