Hi Josh, > This is similar to what Ansii thinks the behaviour should be. But we don't > know if a user has provided the field, or if the field is being repurposed > from the underlying field (for F() expressions), or if it was derived > internally. >
I was thinking you'd instantiate the field without the constraints in _resolve_output_field, i.e. when output_field is None. Essentially it's the same as the "just provide a class" approach: it would require a contract which says all fields must be able to be instantiated in an output_field-compatible (i.e. "unconstrained") way by providing no arguments. That seems related to the limitation in DecimalField that we're talking about correcting anyway. Do you have a feeling of how near or far Django's built-in fields are of meeting that requirement currently? > We could instantiate with no args, but I'm not sure that's a better API. > It's nicer at least in the sense that you don't ignore constraints. The lack of constraints on the output field is implied by the API. I quite like that. Cheers, Alex -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6f1d1945-104a-49ab-87e4-a3505c09c27d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.