Dear all, I kind of agree with Aymeric, increasing last_name to max=60 characters would already be good enough for this proposal and should cover 99.99% of users without breaking backward compatibility.
I support your idea of a built-in User model not based on first and last name. But that sounds too much of a challenge for me at the moment. I'm also missing some data to back up this claim, but 30-50 characters for last_names in Brazil sounds about right. I will check some databases I have access, but my opinion is that this is already going in a good direction! Thank you all for the support and discussion. Kind Regards. _____________________________________________ Raony Guimarães Corrêa Do Carmo Lisboa Cardenas PhD in Bioinformatics email: raonyguimar...@gmail.com skype/hangouts: raonyguimaraes phone: +48 722 148 478 _____________________________________________ On Mon, Aug 1, 2016 at 3:45 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello James, > > > On 01 Aug 2016, at 15:03, James Pic <james...@gmail.com> wrote: > > > > Aymeric, it doesn't matter if tens of milions of names fit into your > > model, it only takes one to have a issue that's going to require the > > project developers to invest time in it. > > I’m not an adept of the “worse is better” school of thought. I believe > that fixing the problem for 99,9999% of people while not creating new > problems for anyone matters. > > There will always be cases where django.contrib.auth doesn’t work ideally. > What matters is the ability to argue that a particular case is enough of an > edge case not to be worth dealing with, and the person who finds themselves > in that case to expect and accept that answer. Clearly “name over 30 > characters” isn’t sufficiently rare to meet this criterion. (It was fine > when it just had to work for LWJ’s staff.) > > Some organizations will have a cost/benefit approach to this question. > Making the problematic cases less frequent reduces the chances that the > benefit of fixing them justifies the cost. Then developers don’t have to > invest time in it. Other organizations will reject the notion of cost and > have a more philosophical approach; that’s harder to discuss in general but > solving a problem while not introducing any new problems still makes the > situation better for them. At the very least they get a better base to > build upon. > > Anyone who likes using an absurdly long last name, for whatever reason, > and enjoys typing it just to get a “name too long” error message on every > website knows how to fix it: use a subset of their name. They’re already > doing it whenever they fill a form, whether on paper or on screen. Paper > forms usually don’t have room for writing names on multiple lines. > > Can you just let use improve the situation for tens of millions of > Brazilian users? It doesn’t cost you, or anyone else, anything. Just let us > make things better for tens of millions of people and not make them worse > for anyone. > > To be extremely clear, let me repeat once again: I’m not trying to make > django.contrib.auth to work for everyone, I know that it still won’t work > for everyone and I accept that my proposal doesn’t attempt to solve the > problem of names entirely. It has been abundantly explained in this thread > why it’s impossible to do something that works for everyone anyway. If we > wanted to do something that worked for significantly more people, we’d > start by dropping the first / last name fields. You’re welcome to make a > proposal in that direction, but I would kindly ask you to do it a a new > thread and let us solve that stupid name length problem for tens of > millions of Brazilian users in this thread. > > > > So I'm a bit lost about what's the most practical approach here. > > Per my definition of “practical”, fixing 99,9999% of a problem with a very > small effort like I suggested is a practical approach. > > > -- > Aymeric > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe > . > To unsubscribe from this group and all its topics, 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/ED879BC4-F89D-48D6-9B09-2778FBDBF998%40polytechnique.org > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CALenahmzbDU7GOM8x%2BxN1gCS4woAOFrUs_CipFnpq9cOVYogJA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
