On 08/06/12 17:42, Carl Meyer wrote: > Hi Andrew, > > On Thursday, June 7, 2012 11:17:51 AM UTC-6, Andrew Godwin wrote: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and keyword arguments you would > have to pass into the constructor to make the field again (as > there's no > way to get them directly). For those familiar with south_field_triple, > it would be a bit like that. > > There will have to be some restrictions on what can be returned as > valid > values - no values that are pre-made anonymous functions, for example - > but that can be cleared up later. > > > If you're allowing named callables, but not anonymous ones, that implies > that you'll be looking up the named ones by import path? Does this not > present the same issue as with Fields - if the callable moves, the > migration breaks? Or am I misunderstanding?
See my reply to Jacob about the same situation - yes, that's the case, but it's mitigated somewhat by an easy way of collapsing old migrations (with bad callable references) down. This proposed one would be just like how fields currently work in South. > > - Requiring all fields to be accessible by only their app label and > class name/other unique name. > > This means either having to register custom fields (like admin classes, > for example), or requiring fields to live in a fields.py or fields > package (like models and models.py). This is to provide for a > less-fragile way of referring to them than their full module path > (which > might change based on project name or package location). > > Neither of these two options is perfect - registration means a little > more "boilerplate" code, while requiring them to be in a certain module > is going to hurt apps that don't have them there already. For that > reason, I prefer the registration approach - it will only be one extra > line per field, it's a pattern already used for admin classes and > filters/tags, and it will allow for field classes to be renamed while > keeping the same registered name (if someone wants). > > > Yuck. I am not at all convinced that this cure isn't worth than the > disease. In every case where Django has introduced flattened > pseudo-namespaces in place of Python's existing namespace system, I > think it's come back to bite us later. > > How bad is it really to do nothing here? If I understand correctly, it > would simply mean that you have to keep a Field class always importable > from the same location, or else manually fix the import location in > older migrations. Frankly, given how rarely I've seen this issue in > practice with South, I think this limitation is perfectly fine, and > much, much, better than introducing a whole new registration machinery > and flattened pseudo-namespace for Fields. You're entirely correct that that's the restriction, and given that I'm imposing precisely the same restrictions on default callables, you may well be right here - after all, "Namespaces are one honking great idea -- let's do more of those!". I think, unless anyone has an objection I can't think of, we should do what you suggest, and just use full paths; after all, third-party apps will have to keep aliases to fields in the right place so imports don't break - registration would just be giving them one more thing to add an alias to. 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.
