Re: Replacing the contrib.sites Site model with a setting?

What if this list of sites needs to be changed dynamically without app restart (multitenancy)? On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham wrote: > In another thread about adding a "scheme" field to the Site model [1], I > floated the idea of moving the data stored by the Site model

Re: Deprecate Cache.has_key()?

Isn't this so it complies with the dict interface? True, it's discouraged now, but it's still there. On 30 January 2016 10:42:12 am LHDT, Tim Graham wrote: >Also the template BaseContext class has an undocumented has_key() >method. I >wonder if that can be removed

Re: Deprecate Cache.has_key()?

Also the template BaseContext class has an undocumented has_key() method. I wonder if that can be removed without a deprecation? https://github.com/django/django/pull/6066 On Friday, January 29, 2016 at 6:11:54 PM UTC-5, Tim Graham wrote: > > Any opposition to deprecating Cache.has_key()? Cache

Deprecate Cache.has_key()?

Any opposition to deprecating Cache.has_key()? Cache already implements __contains__() so converting has_key() to "in" can be done with existing versions of Django. Anyone using flake8 will get a warning about has_key() usage: W601 .has_key() is deprecated, use 'in'. -- You received this

Re: Replacing the contrib.sites Site model with a setting?

This is just that I'm doing in django-sites package: https://github.com/niwinz/django-sites . + to have the similar approach in django (sites as settings). On Fri, Jan 29, 2016 at 10:45 PM, Tim Graham wrote: > In another thread about adding a "scheme" field to the Site

Re: Query on BooleanField with values other than True and False, bug or intentional?

Sorry, sbrandt noted the issue of subtle bugs, not Maxime. On Friday, January 29, 2016 at 4:37:51 PM UTC-6, Chris Foresman wrote: > > I have to agree here; it's pretty sloppy to not enforce an explicit > boolean value and can lead to subtle bugs. In addition to the one mentioned > by Maxime,

Re: Query on BooleanField with values other than True and False, bug or intentional?

I have to agree here; it's pretty sloppy to not enforce an explicit boolean value and can lead to subtle bugs. In addition to the one mentioned by Maxime, consider the case of a nullable boolean field: >>> bool(None) False Maybe that field has a better converter for possible values and

Re: Replacing the contrib.sites Site model with a setting?

> On 29 janv. 2016, at 21:45, Tim Graham wrote: > > Do you think we'll be better off in the long run with a setting as opposed to > storing the data in the database? Yes. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django

Re: Replacing the contrib.sites Site model with a setting?

+1 on setting. That's what I've ended up doing on all of my projects anyhowways. On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham wrote: > > In another thread about adding a "scheme" field to the Site model [1], I > floated the idea of moving the data stored by the Site model into a

Replacing the contrib.sites Site model with a setting?

In another thread about adding a "scheme" field to the Site model [1], I floated the idea of moving the data stored by the Site model into a setting: I've sometimes thought that the Site model violates the principle that you shouldn't put configuration in your database. I guess there's some

Re: argon2 PasswordHasher

Hi Marc, To be clear, I think we shouldn't make Argon2 the default just yet. I would rather add it as an option for now and make it the default in a later release. However, I would like to discuss what would block making Argon2 the default already. > It is once per user, but it's once for

Re: deprecate CommaSeparatedIntegerField?

Thanks for feedback. Created ticket for the deprecation: https://code.djangoproject.com/ticket/26154 On Thursday, January 21, 2016 at 3:06:39 AM UTC-5, Shai Berger wrote: > > On Thursday 21 January 2016 09:59:49 Aymeric Augustin wrote: > > > On 21 janv. 2016, at 07:24, Josh Smeaton

Re: argon2 PasswordHasher

It is once per user, but it's once for *EVERY* user when that scenario occurs. That could easily bring a site down if sessions were invalidated or you have short session times. It's far too likely someone will have serious, hard to debug problems as a result of this magical behaviour. I also

Re: argon2 PasswordHasher

I may not understand the security implications here properly, but as far as I can tell there isn't a strong enough case that Argon2 is fundamentally better than PBKDF2 yet?Barring any weakness in Blake2 we do not know about, Argon2 is way better than PBKDF2 as it is memory-hard.  The gap between

Re: argon2 PasswordHasher

I may not understand the security implications here properly, but as far as I can tell there isn't a strong enough case that Argon2 is fundamentally better than PBKDF2 yet? At least no more than people's arguments that BCrypt is better. I think retaining the simple out of the box experience where

Logged out sessions are resurrected by concurrent requests (ticket 21608)

Hi, everyone! I confirmed this (21608) non critical security bug a while ago and have sense then made a unit test and a fix for it. I have not gotten any feedback on my PR yet, is there something more I need to do to have someone look at this? Best Regards Tore Lundqvist -- You received this

Re: [#26151] Refactor MigrationWriter.serialize() to use a factory pattern

I doubt that serialization support is "feature complete", given some recent history. I guess it would be nice to have the hook so that users don't have to wait for the next release of Django. Django 1.8.1: Added support for serializing datetime.timedelta objects. Django 1.9: Added support for

[#26151] Refactor MigrationWriter.serialize() to use a factory pattern

Hi all, Ticket: https://code.djangoproject.com/ticket/26151 PR: https://github.com/django/django/pull/6059 This pull request suggests to rewrite the serialization in the MigrationWriter to dedicated classes which are then used by a factory function. The reasoning behind this is to reduce the

Re: argon2 PasswordHasher

Hi all, The PR[1] that adds Argon2 as a PasswordHasher is ready to be merged. It does not make Argon2 the default. The reasons not to make it the default are: 1. Argon2 is young. (Its design, though, is uncontroversial.) 2. Argon2 requires C-bindings and thus does not work on every platform