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.

Reply via email to