Hi Andrew -- Generally I'm +1, and I think I see the point pretty clearly. Just a couple of questions:
On Thu, Jun 7, 2012 at 7:17 PM, Andrew Godwin <and...@aeracode.org> 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. I'm not sure I follow this limitation -- you're not saying that things like `datetime.now` would be verboten, right? At least for defaults, callables are pretty common. > > - 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). Can't this be done by auto-discovering subclasses of Field (Field.__subclasses__)? Jacob -- 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.
