FWIW I agree with Florian:
- Where the default is unsuitable for a project, it's easier to restrict
the field's length in forms than to increase it in the User model.
- It's hard to imagine a situation where a 100-character limit is
suitable but a 150-character limit isn't.
- I ca
On Wednesday, August 10, 2016 at 5:34:44 PM UTC+2, Tom Christie wrote:
>
> I'd always defer towards humanized limits, rather than technical limits,
> so I'd suggest 100 chars seems like a decent cap.
>
Not trying to troll or derail, but can we please make it 150 chars? It is
still kinda "humaniz
Ok.
I agree we can set for an increase to 100 characters :)
Cheers
_
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 10 Aug 2016, at 17:34, Tom Christie wrote:
>
> I'd always defer towards humanized limits, rather than technical limits, so
> I'd suggest 100 chars seems like a decent cap.
Yes.
Repeating my earlier message:
> I’m -1 on basing the decision of “how long a last name does Django allow by
>
I'd always defer towards humanized limits, rather than technical limits, so
I'd suggest 100 chars seems like a decent cap.
--
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
Hi,
Now that this thread went silent for a few days, can we reach a consensus
and try increase last_name to the maximum size available without breaking
backward compatibility ?
Please, lets make Django more available to the rest of the world. This is a
small change with a huge benefit to use
Our main database in my division contains about 150,000 users total - from
across the world. Although the distribution is heavily weighted towards
North America and Europe, we do have a fair amount of Asian schools, and
one from Brazil. Many of these schools also have international students. I
Hi,
> Anyway, it seems that this issue is bound to die in a bikeshedding fest,
> so I’ll leave it there, with my apologies to Brazilian users who will
> remain unable to log into Django-based websites :-(
Please don't let this issue die because we cannot reach consensus between
60, 100, 192 and
Thank you Malcolm!
Let's see if we can reach a consensus in a reasonable time.
_
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 Tue, Aug 02, 2016 at 06:09:00PM +0300, Shai Berger wrote:
> Well, there's one precedent that is quite pertinent here, and that
> is AUTH_USER_MODEL. But a setting for the length of a field in a
> built-in app is problematic because it would imply a migration in
> that app, rather than user apps.
Well, there's one precedent that is quite pertinent here, and that is
AUTH_USER_MODEL. But a setting for the length of a field in a built-in app is
problematic because it would imply a migration in that app, rather than user
apps.
In principle we could write the d.c.auth migration by hand to t
On 02 Aug 2016, at 14:23, James Pic wrote:
> I understand it can sometimes be hard for you
Indeed, some aspects of this discussion frustrate me and that showed in my
answer. Please accept my apologies for the unwarranted aggressiveness.
On an intellectual level, I understand why it’s more imp
I've opened ticket 26993 to track this -
https://code.djangoproject.com/ticket/26993#ticket
On Friday, 29 July 2016 12:15:43 UTC+1, Raony Guimaraes Corrêa Do Carmo
Lisboa Cardenas wrote:
>
> Hello everyone,
>
> For a long time I was having problems to login to djangopackages.com
> using my gith
I thought about that before I posted. I can't remember seeing any settings
that would also carry db consequences other than adding an app. (Or the db
setting dict itself).
On Tuesday, August 2, 2016, Malcolm Box wrote:
> A setting seems like a dangerous option here, since changing it would
> cau
A setting seems like a dangerous option here, since changing it would cause
a DB migration to be required.
It's not *that* hard for us to find a value and apply it. Any user that
really wanted something different could create their own migration to
change the default - but "leave it to the user" s
I know there's always resistance to adding more settings but this seems
like a candidate for a value in a setting with a sane default that a user
could quickly and easily change.
On Tuesday, August 2, 2016, James Pic wrote:
> Thanks for your reply Aymeric. If I understand correctly the best way
Thanks for your reply Aymeric. If I understand correctly the best way to
approach this, besides increasing the current limits - which I've had to do
myself a few times - is to create a separate app providing a custom model
with an ArrayField for name (sorting) and a migration script, and let time
t
Someone mentioned mysql not supporting nicely string of 255 unicode characters.
2016-08-02 13:42 GMT+02:00 Malcolm Box :
> Hi Aymeric,
>
> I'm sorry that you feel this has devolved to a bikeshedding fest, that
> certainly wasn't my intent, and I'd hate to see this issue die. I think we
> both agre
Hi Aymeric,
I'm sorry that you feel this has devolved to a bikeshedding fest, that
certainly wasn't my intent, and I'd hate to see this issue die. I think we
both agree that supporting people's names is important - which is the main
thing.
To summarise the available options discussed so far:
Sta
Hello Malcolm,
> On 02 Aug 2016, at 10:28, Malcolm Box wrote:
>
> Having read the W3C Q&A carefully, the relevant comment on field lengths is
> "avoid limiting the field size for names in your database".
Indeed. I chose to propose something else because I didn’t want the solution to
depend o
Hi Malcolm,
It seen everyone here agree 30 characters is not enough for last names and
this should be changed. I also think 255 characters would cause less
trouble in a sense, cause we wouldn't have to deal with this problem again
until we decide to go full TextField. which is actually the bes
On Monday, 1 August 2016 13:56:55 UTC+1, Aymeric Augustin wrote:
>
> > On 30 Jul 2016, at 23:15, Donald Stufft >
> wrote:
> >
> > See #6 of
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
>
>
> I’m aware of this article. It's a entertaining read but, unlike
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
Hello James,
> On 01 Aug 2016, at 15:03, James Pic 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 o
I agree with Aymeric. Short of actual stats stating otherwise, I think we
should use max_length=60 and accommodate most people on the planet out of
the box without a non-trivial amount of time/effort. For those who want to
go above an beyond for a handful of potential users, they can create a
custo
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. So I'm a bit lost about
what's the most practical approach here.
--
You received this message because you are subscrib
> On 30 Jul 2016, at 23:15, Donald Stufft wrote:
>
> See #6 of
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
I’m aware of this article. It's a entertaining read but, unlike the W3 Q&A
mentioned earlier, it doesn’t contain actionable advice for designing a g
As I watch this discussion I am reminded of a talk I saw a few years ago
at PyConAU:
https://www.youtube.com/watch?v=_V4q0o-nKp4&list=PLs4CJRBY5F1KDIN6pv6daYWN_RnFOYvt0&index=33
--
Curtis
On 01/08/16 09:34, James Pic wrote:
On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton wrote:
I think havi
On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton wrote:
>
> I think having a single name field is reasonable for the vast majority of
> cases, but it fails where projects really do need to identify two names for
> things like sorting or categorising.
I'd be willing to believe that a project requires
On Sunday 31 July 2016 00:15:57 Donald Stufft wrote:
> > On Jul 30, 2016, at 4:40 PM, Aymeric Augustin
> > wrote:
> >
> > I have trouble believing that a significant number of people are used to
> > typing 100+ characters when inputting their name into a website — let
> > alone that a significant
+0 to extending the length, but the 255-character maximum in MySQL
shouldn't be a concern since MySQL 5.0.3 (IIRC). I'm all for the ease of a
length increase to the concern raised in the original post. While it would
be nice to do more in the long term, that's a bigger discussion, as Aymeric
po
> On Jul 30, 2016, at 4:40 PM, Aymeric Augustin
> wrote:
>
> I have trouble believing that a significant number of people are used to
> typing 100+ characters when inputting their name into a website — let alone
> that a significant number of people have a last name that contains more than
>
Hello,
> On 30 Jul 2016, at 10:52, Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas
> wrote:
>
> So I'm suggesting a change from 30 to 255 characters on last_name field,
> which is the maximum possible without breaking backwards compatibility.
I’m -1 on basing the decision of “how long a last
On Saturday, July 30, 2016 at 3:25:35 PM UTC+2, Raony Guimaraes Corrêa Do
Carmo Lisboa Cardenas wrote:
>
> So I'm suggesting a change from 30 to 255 characters on last_name field,
> which is the maximum possible without breaking backwards compatibility.
> Maybe on Django 3 we can propose a cha
Hello all, here are my thoughts after reading the discussion.
@Erik You won on having the biggest name! Regarding your question about
"how long is long enough", after checking other web frameworks such as
rails
(http://stackoverflow.com/questions/3354330/difference-between-string-and-text-in-ra
> Nowadays I just go for a single and long name field and I would like to
suggest that django.contrib.auth takes this path too because the first name
and last name system isn't international and django is for building
websites on internet which is meant to be a communication tool connecting
Hum
Indeed first and last name dont make sense en various culture. In the
Memopol project for exampe where wé have a table of European Parliament
representative we have all sorts of names including (The Earl Of) name
suffix which is part of the reasons our first / last name system was
completely checkm
Hello,
I usually build my projects upon these recommendations, but the UX is awkward
and the end result tends to be short_name = first_name and full_name =
first_name + space + last_name.
We could discuss the usefulness of providing an alternate user model that has
short_name + full_name inste
The W3C have some recommandation on the question.
https://www.w3.org/International/questions/qa-personal-names
2016-07-29 17:47 GMT+02:00 Aymeric Augustin
:
> Hello,
>
> Indeed, Django’s default limit on last name length doesn’t work well for
> Brazilians (at least).
>
> Actually having a `first
Hello,
Indeed, Django’s default limit on last name length doesn’t work well for
Brazilians (at least).
Actually having a `first_name` and `last_name` field doesn’t work well in
various cultures, including the US when you want a middle initial. Custom user
models are the general answer to that
Hello Raony,
I'm sure I'm not aware of all the implications of changing the field length,
but the first question should be "how long is long enough"? In answering this
question, this Quora question comes to mind:
https://www.quora.com/Why-are-South-Indian-names-often-long
Kind regards,
Erik
a.
41 matches
Mail list logo
