Hi Shai, On Saturday, February 27, 2016 at 4:44:18 PM UTC+1, Shai Berger wrote: > > I think this is why we should be a little more cautious and go for 128 or > 100, > rather than "the current maximum all-backend-compatible value". >
Which somewhat speaks for my point, cause we do not know if the next backend will need less than 100 chars (But I do agree that this is not likely). Tough I think that 100 (or 191 for matter) is a ridiculously low limit. In that sense, allowing max_length=None is probably the safest solution -- even though we do not know when database backends will crash on this, but we do not know this for text fields either currently. > That all said, if it were for me I'd deprecate CharField and only support > > TextField and give it an optional max_length (and a way to switch > between > > TextArea and LineEdit for UI) -- but that is probably just because on > > Postgres there is no fundamental difference between them. From an > enduser > > perspective, it is all text, the only difference is a constraint in > length, > > No, that's not the only difference. There's also an understanding that > CharField's are one-liners, that is, there is an implicit limitation > (usually > only enforced by UI) that newlines are not allowed in the text. > This is a leaky abstraction at best in my opinion. The "understanding" is mostly coined by the documentation in the sense that it mentions <textarea> for TextField and <input> for CharField. So it is kind of illogical to not allow a max_length on TextField. Even with model.full_clean there is no restriction aside from the length, in that sense a CharField behaves completely the same as TextField (database issues with index lengths etc excluded). For example, I don't > think there are many CharField's whose contents are interpreted as markup. Maybe, maybe not, I do not see how this makes a difference here though. (Same goes for Regex validation). > In a user perspective, these are really different data types. Which can be dangerous on it's own, I'd have to check, but I am pretty sure that nothing prevents the user from submitting newlines in a CharField. > I find your suggestion > analogous to a suggestion to remove IntegerField, because "it's just a > FloatField with a constraint on scale". > I'd suggest a DecimalField cause I do not like FloatFields either, but yeah ;) Do not get me wrong, I somewhat agree with everything you say (in the end I think it is just a matter of taste) -- but I also think that explicit is better than implicit. From a security point of view, I agree that length validation should be done whenever it makes sense [which is basically always, there is no point in allowing to post the maximum length of a TextField, especially not if it contains markup which you have to render again ;)], so a CharField with a default max_length seems like a good idea. On the other hand I think that it will make the distinction for new users even harder. Assume we change the CharField to have a default max_length, the first (and probably only thing) users will notice is that CharField is single line. I am somewhat reading #django 24/7 and can tell you that no matter how much we write in the docs, users are reading them less and less. So for all practical purposes a single field allowing for all of that is imo the best abstraction. Cheers, Florian -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/df712817-b19e-411d-b810-2a9bdd42d904%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
