Take a simple Model and ModelForm like this:
class Author(models.Model):
name = models.CharField(max_length=80, blank=True, default="Joe",
help_text="A name")
class AuthorForm(forms.ModelForm):
class Meta:
model = Author
The resulting form will reflect the desired help text,
> Well, surprise is in the eye of the participant. As noted above, it
> would be surprising to a lot of us if it did pick up the attributes
> because it removes control from the user. The current behaviour isn't
> illogical.
Oh, I wasn't suggesting that the user shouldn't be able to override
In terms of backward compatibility, perhaps there could be a new
keyword argument to Field, something like with_model_defaults, that
the user would use to indicate a desire to get the attributes from the
Model. How would this work? Maybe something like this (this is just a
sketch):
> Please file a ticket for the documentation fix it would be greatly
> appreciated. :-)
Will do.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
> > Thanks, the accompanying discussion is very interesting and on point.
> > But as someone there points out, why stop at widgets?
>
> Because customizing widgets is a common request, unlike other attributes.
But customizing fields is quite common, no? I agree that it's rare
that you will want
ions will
> succeed if you swap out the attached tzinfo for a zoneinfo tzinfo.
>
> If we go with any variation of using shim-around-zoneinfo like
> pytz-deprecation-shim, I'd say those shims need to be introduced as a
> breaking change in Django 4.0. If we go with shim-around-pyt
I think that the simplest approach—the one that would result in the least
amount of total work for both Django and its users—would be to adopt Nick's
suggestion and just switch to zoneinfo in 4.0. The problem is that it's
very hard to square that with Django's stability policy: "We’ll only
Thanks to Paul for this proposal, and for working to put proper timezone
usage into Python itself. PEP 495 and 615 definitely make Python better,
and it seems inevitable that everyone will sooner or later switch over. I'm
all for getting this process going in Django.
I have doubts over whether
> The point about the arithmetic semantics is a good one. I'm curious to
> know how often this is actually a problem.
>
That’s an interesting question. I think that doing localized datetime
arithmetic in Django is idiomatic, if not necessarily common. Let’s say we
have a calendar application
