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? - 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. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/hTlDL9sLsJMJ. 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.
