On 08/06/12 16:45, Jacob Kaplan-Moss wrote: > 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.
No, that'd be allowed (and already is in South) - it's just edge cases like, for example, def'ing a function inside the method that returns the arguments and then using that as a default - there's no way to serialise that other than by using its code object. The basic restriction will be that you're allowed callables, but they must be importable by another module and that they're available as long as the migration they're in exists. That second point will be helped by a much easier way of collapsing old migrations and removing out-of-date references. > >> >> - 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__)? It could - however, that would mean that we'd have to enforce unique naming rules for fields inside an app (not really a problem), and that people making fields inside a function or other weird situation might have those fields detected (could cause some weird issues). The other problem with that is the inability to change a field's class name without breaking old migrations (whereas with a template-tag-like registering approach you could optionally provide a different name to register it as, thus allowing it to exist under two names). Still, it's a hard balance to strike, really - registering is still a little clunky, and we can't (yet) rely on things like class decorators to make it nicer. 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.
