On 11/06/12 10:27, Anssi Kääriäinen wrote: > All of the above sounds good - my main worry was that if you subclass > a field, then it will not get a rule match as the module path prefix > will be different than the parent field's. I don't know if this is an > issue even in South... But if the rules are part of the field API, > then there is no worry. Are the rules even needed after the > introduction of "get_init_args()"?.
Nope, the whole point of introducing this stuff is to get rid of the rules. That will make me a happy man. > The only possible problem with using the module path as the identifier > is the inability for the user to replace removed fields with copied > backwards compatibility code. As this is probably a non-issue (and > possible to work around) I will surprise you all and not complain > about this :) I think that the case of a field being removed completely is rare enough that this is acceptable (having to use a workaround). Most times a field becomes unimportable it will likely have moved, in which case a good number of apps would keep the old import working (as code probably depends on it). But yes, I'll stop now before you complain again :) Andrew -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
