Re: anyone working on adding Django 1.10 support?

[Iacopo Spalletti]

On 03/08/2016 05:45, Jonas Obrist wrote:
> People are reporting some changes in 1.10 "breaks everything" in
> sekizai/classytags/better-test etc, but it sounds like things are
> working for you? I haven't had time yet to investigate, so how urgent
> are fixes/updates to those dependencies for you?
> 

The only breaking change I encountered so far in
sekizai/classytags/better-test is the dropped support for optparse, the
rest looks fine


> On Wednesday, August 3, 2016 at 3:33:42 AM UTC+9, Tim Graham wrote:
> 
> I should have asked this before Django 1.10 was released, but here I
> am now. I like to monitor if third-party packages run into any
> unexpected issues, so please ping me when there's a PR for this so I
> can take a look.
> 
> -- 
> Message URL: *MailScanner has detected definite fraud in the website at
> "groups.google.com". Do /not/ trust this website:*
> https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id 
> 
> Unsubscribe: send a message to
> django-cms-developers+unsubscr...@googlegroups.com
> ---
> You received this message because you are subscribed to the Google
> Groups "django CMS developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-cms-developers+unsubscr...@googlegroups.com
> .
> To view this discussion on the web, visit *MailScanner has detected
> definite fraud in the website at "groups.google.com". Do /not/ trust
> this website:*
> https://groups.google.com/d/msgid/django-cms-developers/73f880cb-5155-4393-9227-8fcc26463a84%40googlegroups.com
> .
> For more options, visit *MailScanner has detected definite fraud in the
> website at "groups.google.com". Do /not/ trust this website:*
> https://groups.google.com/d/optout .


-- 
Iacopo Spalletti

Nephila s.a.s. - Firenze
Telefono: +39 055 5357189
Assistenza Tecnica: +39 055 3985730
http://nephi.la

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/9fd06a15-364e-7bf6-1516-58f86c38f306%40nephila.it.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: anyone working on adding Django 1.10 support?

[Jonas Obrist]

People are reporting some changes in 1.10 "breaks everything" in 
sekizai/classytags/better-test etc, but it sounds like things are working 
for you? I haven't had time yet to investigate, so how urgent are 
fixes/updates to those dependencies for you?

On Wednesday, August 3, 2016 at 3:33:42 AM UTC+9, Tim Graham wrote:
>
> I should have asked this before Django 1.10 was released, but here I am 
> now. I like to monitor if third-party packages run into any unexpected 
> issues, so please ping me when there's a PR for this so I can take a look.
>

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/73f880cb-5155-4393-9227-8fcc26463a84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Tim Allen]

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 
hope some insights on these data may prove valuable.

We currently have fields for first name (max length=50), last name (max 
length=50), and full name (max length=100). These are in SQL Server (we are 
converting to PostgreSQL, one step at a time) and of type NVARCHAR, so 
that's inclusive of byte length for Unicode characters.

Even with our single Brazilian school, I can see the need for a last name 
field longer than 50 characters, and definitely longer than 30. We also 
have quite a few users who have chosen to populate their last name fields 
with input like 'Lastname (Sr John Huntsman Prof of Awesomeness)' in their 
last name field, where they've abbreviated due to the field length. Yes, 
that would be more appropriate for a title field, but I suspect we are not 
alone in having users exhibit / want this flexible behavior, so it appears 
everywhere their name does.

My two cents? Setting username, first_name, and last_name in Django to a 
max_length of ~192 would cover the most users, be backwards compatible even 
with MySQL < 5.0.3, and give a lot of flexibility to the developer. It is 
quite possible I've missed something, but figured I'd throw some 
observations based on our users out there. Thanks for the discussion.

Regards,

Tim

-- 
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/5bdcc162-fb9a-4f3f-afc7-2d4129667f8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need help with MySQL 5.7 crashing on Django's Jenkins

[Erik Cederstrand]

I think this is better directed at a MySQL list. MySQL shouldn't crash, nothing 
I see indicates that this is a Django issue.

Of course, it's best if you can reproduce the error. Barring that, you'll get a 
much more useful stack trace if you build MySQL with debugging symbols. A quick 
look at the stack trace does indicate that your problem is in either libpthread 
or libc, which is unlikely - is it possible that you have hardware issues?

Erik

> Den 2. aug. 2016 kl. 02.05 skrev Tim Graham :
> 
> Sometimes the MySQL 5.7.13 builds on Ubuntu 16.04 are failing with "Lost 
> connection to MySQL server during query" because the MySQL server restarts 
> during the tests. I wonder if anyone has an idea about how to solve this. 
> Looking through the MySQL error log, I think this is the root cause:
> 
> 2016-08-01T23:02:56.636617Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has 
> lasted > 600 seconds. We intentionally crash the server because it appears to 
> be hung.
> 2016-08-01 23:02:56 0x7f5fb75d8700  InnoDB: Assertion failure in thread 
> 140049074980608 in file ut0ut.cc line 920
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
> InnoDB: If you get repeated assertion failures or crashes, even
> InnoDB: immediately after the mysqld startup, there may be
> InnoDB: corruption in the InnoDB tablespace. Please refer to
> InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
> 23:02:56 UTC - mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
> Attempting to collect some information that could help diagnose the problem.
> As this is a crash and something is definitely wrong, the information
> collection process might fail.
> 
> key_buffer_size=536870912
> read_buffer_size=131072
> max_used_connections=4
> max_threads=151
> thread_count=4
> connection_count=4
> It is possible that mysqld could use up to 
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 584285 
> K  bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
> 
> Thread pointer: 0x0
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 0 thread_stack 0x20
> /usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe7bdab]
> /usr/sbin/mysqld(handle_fatal_signal+0x489)[0x783759]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x7f60131dc3d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f6012596418]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f601259801a]
> /usr/sbin/mysqld[0x759764]
> /usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0x145)[0x110c905]
> /usr/sbin/mysqld(srv_error_monitor_thread+0xe2d)[0x10aa34d]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f60131d26fa]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6012667b5d]
> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
> information that should help you find out what is causing the crash.
> 
> -- 
> 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/3f787f25-2e3f-49b1-b6a3-7a3411e70a9b%40googlegroups.com.
> 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/8F9A7704-1A29-4EBB-8AD7-FF3CAB398416%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: UTF-8 name of a staticfiles test is breaking Django installation

[René Fleschenberg]

Hi everyone,

> Can we consider “update setuptools” to be an adequate resolution for this
> issue?

I realize this is probably not the most substantial argument, but I want to 
mention it anyway: Considering Django's popularity, requiring a recent 
version of setuptools might be a positive side-effect on the larger Python 
ecosystem. The prevalence of old setuptools versions can be rather annoying. 
For example: https://hynek.me/articles/conditional-python-dependencies/

-- 
René Fleschenberg

-- 
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/5063025.TKyiib2vOM%40rex.
For more options, visit https://groups.google.com/d/optout.

Re: UTF-8 name of a staticfiles test is breaking Django installation

[Aymeric Augustin]

Hello,

Django used to create this file dynamically while running tests, but that got 
in the way of test parallelization. To avoid race conditions, the git checkout 
needs to be treated as readonly when running tests in parallel.

That’s why I switched to committing it to the git repository when I implemented 
test parallelization. I assumed all relevant systems for Django would support 
utf-8 by now… I was too optimistic!

Can we consider “update setuptools” to be an adequate resolution for this issue?

-- 
Aymeric.

> On 02 Aug 2016, at 18:03, Berker Peksağ  wrote:
> 
> On Tue, Aug 2, 2016 at 6:14 PM, Tim Graham  wrote:
>> A similar report was https://code.djangoproject.com/ticket/24761. I'm not
>> sure if this is a bug in those install tools or if it's something we should
>> try to fix in Django. You can use `git blame
>> tests/staticfiles_tests/apps/test/static/test/⊗.txt` to find the commit
>> where the file was introduced to learn the reason for it.
> 
> It looks like this is a bug in setuptools:
> https://github.com/pypa/setuptools/issues/709
> 
> --Berker
> 
> -- 
> 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/CAF4280%2BXA9%3DKDAE7CKrgCjY4ttq%2BkxG5VdXZk2p6KdUn5k8VWQ%40mail.gmail.com.
> 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/3FC5B5B0-681F-40F4-A0A6-6915F043C2E7%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: UTF-8 name of a staticfiles test is breaking Django installation

[Berker Peksağ]

On Tue, Aug 2, 2016 at 6:14 PM, Tim Graham  wrote:
> A similar report was https://code.djangoproject.com/ticket/24761. I'm not
> sure if this is a bug in those install tools or if it's something we should
> try to fix in Django. You can use `git blame
> tests/staticfiles_tests/apps/test/static/test/⊗.txt` to find the commit
> where the file was introduced to learn the reason for it.

It looks like this is a bug in setuptools:
https://github.com/pypa/setuptools/issues/709

--Berker

-- 
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/CAF4280%2BXA9%3DKDAE7CKrgCjY4ttq%2BkxG5VdXZk2p6KdUn5k8VWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Michal Petrucha]

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. 
> 
> In principle we could write the d.c.auth migration by hand to take
> the setting in account, and declare the setting as unchangeable like
> AUTH_USER_MODEL, but that would be very ugly special-casing IMO. 

That would be very error prone, unless we wrap in a thick layer of
safety checks. django-allauth already does something like that (where
a migration conditionally adds an operation depending on a setting)
and it has already come up a bunch of times in #django when people got
their database schema into an inconsistent state by changing that
setting.

-- 
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/20160802151714.GG5430%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Extend support for long surnames in Django Auth

[Shai Berger]

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 take the setting 
in account, and declare the setting as unchangeable like AUTH_USER_MODEL, but 
that would be very ugly special-casing IMO. 


On 2 באוגוסט 2016 16:28:11 GMT+03:00, Lee Trout  wrote:
>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
>> 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" still means picking a
>value
>> for the sane default...
>>
>> Cheers,
>>
>> Malcolm
>>
>> On 2 August 2016 at 14:01, Lee Trout > > wrote:
>>
>>> 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 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
 tell if this is more useful than the current approach and wether it
>should
 become default or not after a long-enough while ?

 Again, thanks for your reply, every time I read messages from
>engineers
 like you it makes me a better one myself and I'm sure it's the case
>for
 most other persons. I understand it can sometimes be hard for you -
>and
 other experienced core devs- to have to deal with us, so I really
>want to
 show my appreciation and love and I think I can speak for everyone
>of us
 when I say thank you for your contribution and your sharing and
>making
 everyone of us better every time you take some time for us.

 Keep up the great work

 Best regards

 --
 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/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com

>
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> 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/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com
>>>
>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Malcolm Box
>>
>> --
>> 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 

Re: UTF-8 name of a staticfiles test is breaking Django installation

[Tim Graham]

A similar report was https://code.djangoproject.com/ticket/24761. I'm not 
sure if this is a bug in those install tools or if it's something we should 
try to fix in Django. You can use `git blame 
tests/staticfiles_tests/apps/test/static/test/⊗.txt` to find the commit 
where the file was introduced to learn the reason for it.

On Tuesday, August 2, 2016 at 6:45:28 AM UTC-4, Marcin Nowak wrote:
>
>
>>> I'm using Buildout and virtualenv with Python 2.7.9.
>>>
>>>
>> and setuptools 25.1.2 
>>
>>
> It works with setuptools 17.0, but displays warning:
>
> Getting distribution for 'Django==1.8.14'.
> 'tests/staticfiles_tests/apps/test/static/test/⊗.txt' not ANSI_X3.4-1968 
> encodable -- skipping
> warning: no previously-included files matching '__pycache__' found under 
> directory '*'
> warning: no previously-included files matching '*.py[co]' found under 
> directory '*'
> 'tests/staticfiles_tests/apps/test/static/test/⊗.txt' not ANSI_X3.4-1968 
> encodable -- skipping
> Got Django 1.8.14.
>  
>
> M.
>

-- 
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/00a3a16a-aab8-4edb-9627-961e27258134%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Aymeric Augustin]

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 important for open-source 
software to give room to all opinions than to get to a solution as fast as 
possible, but I’m finding it hard to accept this process when it comes to 
changes I care about and that should have been done years ago. I’m still 
working on it!

-- 
Aymeric.

-- 
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/C4DB4DDB-1CFC-491D-8237-C03FC59D6ED5%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Malcolm Box]

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 github account (pydanny/djangopackages#338 
> ). After 
> investigating I discovered the problem was because my surname is longer 
> than 30 characters. I don't know why both first_name and last_name fields 
> have the same size limit of 30 characters in Django. That doesn't sound 
> very reasonable.
>
> I'm sure there are other people on the same situation and this already 
> happened with me trying to login in other django websites.
>
>
> [image: selection_086] 
> 
>
>
> Tim Graham suggested I should first ask on this maillist (
> https://github.com/django/django/pull/6988#issuecomment-235945422) to see 
> if there is consensus to make the change.
>
> I would like to ask your opinion about an increase from 30 to 60 
> characters on last_name field so that my login and others won't break again 
> in the future. I can create a Trac ticket if the response is positive.
>
> Kind Regards,
>
>

-- 
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/e46bef3f-3680-470e-8fe0-85145872f9b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Lee Trout]

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
> 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" still means picking a value
> for the sane default...
>
> Cheers,
>
> Malcolm
>
> On 2 August 2016 at 14:01, Lee Trout  > wrote:
>
>> 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 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
>>> tell if this is more useful than the current approach and wether it should
>>> become default or not after a long-enough while ?
>>>
>>> Again, thanks for your reply, every time I read messages from engineers
>>> like you it makes me a better one myself and I'm sure it's the case for
>>> most other persons. I understand it can sometimes be hard for you - and
>>> other experienced core devs- to have to deal with us, so I really want to
>>> show my appreciation and love and I think I can speak for everyone of us
>>> when I say thank you for your contribution and your sharing and making
>>> everyone of us better every time you take some time for us.
>>>
>>> Keep up the great work
>>>
>>> Best regards
>>>
>>> --
>>> 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/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Malcolm Box
>
> --
> 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/CAF3R4sVikNLgr1DVtKw_3ps7gFuHrZbO3K1Zhv14ZuUzM5zR0A%40mail.gmail.com
> 

Re: Extend support for long surnames in Django Auth

[Malcolm Box]

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" still means picking a value
for the sane default...

Cheers,

Malcolm

On 2 August 2016 at 14:01, Lee Trout  wrote:

> 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 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
>> tell if this is more useful than the current approach and wether it should
>> become default or not after a long-enough while ?
>>
>> Again, thanks for your reply, every time I read messages from engineers
>> like you it makes me a better one myself and I'm sure it's the case for
>> most other persons. I understand it can sometimes be hard for you - and
>> other experienced core devs- to have to deal with us, so I really want to
>> show my appreciation and love and I think I can speak for everyone of us
>> when I say thank you for your contribution and your sharing and making
>> everyone of us better every time you take some time for us.
>>
>> Keep up the great work
>>
>> Best regards
>>
>> --
>> 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/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Malcolm Box

-- 
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/CAF3R4sVikNLgr1DVtKw_3ps7gFuHrZbO3K1Zhv14ZuUzM5zR0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Lee Trout]

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 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
> tell if this is more useful than the current approach and wether it should
> become default or not after a long-enough while ?
>
> Again, thanks for your reply, every time I read messages from engineers
> like you it makes me a better one myself and I'm sure it's the case for
> most other persons. I understand it can sometimes be hard for you - and
> other experienced core devs- to have to deal with us, so I really want to
> show my appreciation and love and I think I can speak for everyone of us
> when I say thank you for your contribution and your sharing and making
> everyone of us better every time you take some time for us.
>
> Keep up the great work
>
> Best regards
>
> --
> 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/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com
> 
> .
> 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/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[ludovic coues]

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 agree that supporting people's names is important - which is the main
> thing.
>
> To summarise the available options discussed so far:
>
> Status Quo: Do nothing, and fail to handle a large chunk of the world's
> population who's names don't fit in 30 characters
> Radical changes (in order of increasing radicalness):
>  - Change fields to a TextField
>  - Replace last_name / first_name with a single "name" field
>  - Change startproject to default to a custom user model with default fields
> that are in line with W3C recommendations
> Minimal change: Increase the length of the existing fields
>
> As far as I can see, everyone is in favour of the minimal change option NOW,
> and possibly some of the Radical changes later.
>
> So the only remaining disagreement is over the value of max_length to change
> to. Proposals of 60, 100 and 255 have been made.
>
> If I created a patch that set the max_length to 255, would anyone object? If
> so, what's the objection - storage space shouldn't be a concern, and
> breaking a form seems as likely with 60 as 255?
>
> Cheers,
>
> Malcolm
>
> On 2 August 2016 at 12:26, Aymeric Augustin
>  wrote:
>>
>> Hello Malcolm,
>>
>> > On 02 Aug 2016, at 10:28, Malcolm Box  wrote:
>> >
>> > Having read the W3C Q 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 on an implementation of “CharField of unlimited length”.
>>
>> That feature isn’t hard to implement but it involves more difficult design
>> decisions. Look at the archives for this mailing-list for more information.
>>
>> 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 :-(
>>
>> --
>> 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/36DD2C84-E5ED-4646-9857-B6BC5D92BE94%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/CAF3R4sU%3D1gaTk3AGRY7nuQHFX8op9-b00Frc6z_1k69k_R-bNA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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/CAEuG%2BTZ8V%3DP%3D3khdjpB8RTZj_PiZ4R%3D6DatKyixoWshoqZH6_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Aymeric Augustin]

Hello Malcolm,

> On 02 Aug 2016, at 10:28, Malcolm Box  wrote:
> 
> Having read the W3C Q 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 on an implementation of “CharField of unlimited length”.

That feature isn’t hard to implement but it involves more difficult design 
decisions. Look at the archives for this mailing-list for more information.

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 :-(

-- 
Aymeric.


-- 
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/36DD2C84-E5ED-4646-9857-B6BC5D92BE94%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Resolved: wontfix is not productive

[Marcin Nowak]

On Tuesday, July 26, 2016 at 11:16:18 PM UTC+2, Aymeric Augustin wrote:
>
>
> Specifically, please explain why this has to live in Django.

Because Django has an implementation which can be extended without 
rewritting a whole thing from scratch?
Well... it is your decision about "including batteries" into the framework, 
making it full-stack...

I like quite opposite design, personally, but here is a guy who did useful 
improvement and his work was dropped because of... including another useful 
battery. 
I know that every line of code needs to be maintained and you're very 
careful with adding new features. 
But maybe there is a good time to think about decoupling Django?

BR,
Marcin

-- 
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/387c7fc9-bf01-4654-9e71-2fc01be5b352%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UTF-8 name of a staticfiles test is breaking Django installation

[Marcin Nowak]

>
>
>> I'm using Buildout and virtualenv with Python 2.7.9.
>>
>>
> and setuptools 25.1.2 
>
>
It works with setuptools 17.0, but displays warning:

Getting distribution for 'Django==1.8.14'.
'tests/staticfiles_tests/apps/test/static/test/⊗.txt' not ANSI_X3.4-1968 
encodable -- skipping
warning: no previously-included files matching '__pycache__' found under 
directory '*'
warning: no previously-included files matching '*.py[co]' found under 
directory '*'
'tests/staticfiles_tests/apps/test/static/test/⊗.txt' not ANSI_X3.4-1968 
encodable -- skipping
Got Django 1.8.14.
 

M.

-- 
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/9914693c-56cd-43f2-ac19-b763628ce740%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

UTF-8 name of a staticfiles test is breaking Django installation

[Marcin Nowak]

Hi all,

Here is a file which breaks installation on fresh Debian system:
 
https://github.com/django/django/blob/master/tests/staticfiles_tests/apps/test/static/test/%E2%8A%97.txt

I'm using Buildout and virtualenv with Python 2.7.9.

The full traceback is:

Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/project/env/lib/python2.7/site-packages/setuptools/command/easy_install.py",
 
line 2271, in main
**kw
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
  File 
"/home/webcar/env/lib/python2.7/site-packages/setuptools/command/easy_install.py",
 
line 409, in run
self.easy_install(spec, not self.no_deps)
  File 
"/home/webcar/env/lib/python2.7/site-packages/setuptools/command/easy_install.py",
 
line 645, in easy_install
return self.install_item(None, spec, tmpdir, deps, True)
  File 
"/home/webcar/env/lib/python2.7/site-packages/setuptools/command/easy_install.py",
 
line 694, in install_item
dists = self.install_eggs(spec, download, tmpdir)
  File 
"/home/webcar/env/lib/python2.7/site-packages/setuptools/command/easy_install.py",
 
line 845, in install_eggs
unpack_archive(dist_filename, tmpdir, self.unpack_progress)
  File 
"/home/webcar/env/lib/python2.7/site-packages/setuptools/archive_util.py", 
line 52, in unpack_archive
driver(filename, extract_dir, progress_filter)
  File 
"/home/webcar/env/lib/python2.7/site-packages/setuptools/archive_util.py", 
line 148, in unpack_tarfile
prelim_dst = os.path.join(extract_dir, *name.split('/'))
  File "/home/webcar/env/lib/python2.7/posixpath.py", line 80, in join
path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1: 
ordinal not in range(128)
An error occurred when trying to install Django 1.8.14. Look above this 
message for any errors that were output by easy_install.

The path to a file which fails is:
/tmp/easy_install-A3XRR9 
Django-1.8.14/tests/staticfiles_tests/apps/test/static/test/⊗.txt

Is this file really needed in Django dist?

Marcin
 

-- 
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/967785a0-3df7-4454-a2dd-7c5e6875991d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

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 best decision 
(IMHO). 

Regarding breaking the UI, I prefer a website with a broken UI than a 
website I cannot login (Ex. with my github account) because of my name. 
Lesser of two evils.

So how we could reach a consensus between 60 and 255? 60 will cover my last 
name, but not erik's ... I wish we could solve this for everyone and not 
only for me ... :/

Kind Regards.

On Friday, July 29, 2016 at 1:15:43 PM UTC+2, 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 github account (pydanny/djangopackages#338 
> ). After 
> investigating I discovered the problem was because my surname is longer 
> than 30 characters. I don't know why both first_name and last_name fields 
> have the same size limit of 30 characters in Django. That doesn't sound 
> very reasonable.
>
> I'm sure there are other people on the same situation and this already 
> happened with me trying to login in other django websites.
>
>
> [image: selection_086] 
> 
>
>
> Tim Graham suggested I should first ask on this maillist (
> https://github.com/django/django/pull/6988#issuecomment-235945422) to see 
> if there is consensus to make the change.
>
> I would like to ask your opinion about an increase from 30 to 60 
> characters on last_name field so that my login and others won't break again 
> in the future. I can create a Trac ticket if the response is positive.
>
> Kind Regards,
>
>

-- 
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/c2c98e8c-a660-4699-a6ad-33e1014d9577%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Malcolm Box]

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 the W3 Q 
> mentioned earlier, it doesn’t contain actionable advice for designing a 
> generic system that won’t perform too poorly in many use cases when you 
> have no idea of what these use cases will be. 
>
>
Having read the W3C Q carefully, the relevant comment on field lengths is 
"avoid limiting the field size for names in your database". There is no 
reference to 60 characters being "enough".
 

> Last names containing over 30 characters are sufficiently common — likely 
> tens of millions of people at this time — to deserve consideration. That’s 
> where this thread started. Let’s not block an easy win for these tens of 
> millions because the general problem is intractable. Besides, a last_name 
> field is already a severe simplification, as we all know. 
>
> Last names containing over 100 characters are sufficiently uncommon to be 
> the subject of trivia articles on the Internet. I’m absolutely certain that 
> no website has tens or thousands of millions of last names over 100 
> characters; in fact, not even tens of such names. 
>
> If someone has access to real-life stats from a very large database of 
> names in a country that has long last names that could help us make an 
> optimal decision. 
>
>
Aren't we in danger of premature optimisation here? The field lengths are 
currently 30 characters. Even if we expanded it to 255, we would be adding 
at worst 255 bytes to the storage requirements for a user. If a site has 1 
million users, that's 250MB of disk space - which for a site with 1M users 
is unlikely to be significant, let alone the main driver of disk usage. 
After all, with 1M users, you'd only need each of them to do something 
requiring a 200 byte record to use the same amount of space.

For sites with far less users, it's proportionally much less of a problem - 
and those sites are the majority, and hence will benefit most from being 
able to deal with more user's names, while suffering the least cost. Sure, 
we'd be wasting some space on disks - but we'd be enabling Django to serve 
more of the world's population (and allowing sites to just use last_name as 
a full name if they don't want the fun of a custom user model).

So if we don't want to go to full TextField for the username, at least 
let's go to the biggest number possible (currently 255, thanks MySQL).

Premature optimisation is the root of all evil...

Cheers,

Malcolm

-- 
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/161214ba-560e-4ef6-ada8-4eb0067b3181%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.