Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

A new ticket asks how to elegantly handle this in the admin actions where it's easy to post more than 1000 values using the "select all" button. My feeling is that applications shouldn't change their behavior based on this setting, but a consensus on how to proceed here might be useful for

Re: Future of the development server's auto-reloading

A pull request is proposed to add a new setting to allow specifying a custom reloader: https://github.com/django/django/pull/6719 Is this something anyone else would find useful and does it seems like we could continue support that option even if autoreloading is refactored based on the ideas

Re: Google Summer of Code Updates - Class based indexes

Support for more index types is planned. This is only part 1 of the work. Please see https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404 for the timeline. On Monday, June 27, 2016 at 5:02:06 PM UTC-4, thinkwel...@gmail.com wrote: > > Will it be possible to create indexes other than

Re: Google Summer of Code Updates - Class based indexes

Will it be possible to create indexes other than btree? In reviewing the code it doesn't look like it but I hope I'm wrong. It'd be awesome to support the many more specific index options without using run_sql. -- You received this message because you are subscribed to the Google Groups

Re: Google Summer of Code Updates - Class based indexes

This week's work on previous PR: - Change in signature of Index class - Write tests for the Index class - Address all issues on PR The previous PR has been merged. Now indexes can be added using the AddIndex migration

Re: Django Model Fields a repr_output property, to include a field in the string representation of an object

A new model field option doesn't seem necessary. I think a cleaner solution would be something like a decorator that takes a list of fields, e.g. @repr_fields('first_name', 'last_name') class Person(...): ... This doesn't need to live in Django itself though. On Thursday, June 23, 2016 at

Re: change commit message format to present tense?

On Mon, Jun 27, 2016, Reinout van Rees wrote: >Op 26-06-16 om 05:31 schreef Kevin Christopher Henry: >> If anyone's put off by the hectoring tone of the imperative mood, it >> might be better to think of it as the indicative mood. That is: >> >> (This will) "add password

Re: Adding a database-agnostic JSONField into Django

Current maintainer of https://github.com/bradjasper/django-jsonfield here and I would definitely support this. -Brad On Thu, Jun 23, 2016 at 9:28 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > On 23 Jun 2016, at 15:40, Tim Graham wrote: > >

Re: change commit message format to present tense?

Hi, Le lundi 27 juin 2016, Reinout van Rees a écrit : > > (You must) "add password validation to prevent the usage of..."! > > "It might be better to think of it as...": it is exactly this extra > thinkwork that everyone reading the messages has to do. We write it once and > read it many times:

Re: change commit message format to present tense?

Il 27/06/2016 11:49, Reinout van Rees ha scritto: Op 26-06-16 om 05:31 schreef Kevin Christopher Henry: If anyone's put off by the hectoring tone of the imperative mood, it might be better to think of it as the indicative mood. That is: (This will) "add password validation to prevent the usage

Re: change commit message format to present tense?

Op 26-06-16 om 05:31 schreef Kevin Christopher Henry: If anyone's put off by the hectoring tone of the imperative mood, it might be better to think of it as the indicative mood. That is: (This will) "add password validation to prevent the usage of...". rather than (You must) "add password