Re: Migrations and swappable models/AUTH_USER_MODEL

On Wed, 8 Jan 2014 20:27:54 +0200 Shai Berger wrote: > On Wednesday 08 January 2014 20:00:25 Andrew Godwin wrote: > > > Instinctively, I'm almost -1 on 2); I'm not too happy about 1) > > > either. If a model says it has a FK to auth.User, that shouldn't > > > mean anything

Re: Provide a way to pass kwargs when initializing the storage class

Hello, The core of the proposed solution seems quite interesting; however, it also introduces a new configuration format for backends. Caches and databases use a dict with a "BACKEND" key and an "OPTIONS" dict for kwargs to pass to the backend. Likewise, entries in the TEMPLATES list are

Re: Extending JSONField serialization

set a custom decoder/encoder for a JSONField. Being able to only specify the encoding is error-prone, since my code will then have to handle the distinction between "this is a value set pre-save, so it's in a native type" and "this time, it's from the database, so I have to cas

Re: re-thinking middleware

On Fri, 8 Jan 2016 11:38:04 -0700 Carl Meyer wrote: > Thanks everyone for the reviews. I've pushed a new commit addressing > most of the issues raised: > https://github.com/django/deps/commit/62b0ee351727cb0e7ef41ba6dd2f3f7280a219de > > More comments and replies (to various

Re: remove support for unsalted password hashers?

Hi Tim, I would suggest removing those hashers from the default list, but keeping at least the django.contrib.auth.hashers.UnsaltedMD5PasswordHasher around. That hasher, being the fastest non-plaintext hasher around, is quite useful when running tests: it allows login checks to be performed

Re: remove support for unsalted password hashers?

Hi Tim, A few notes here: Just as djangoproject.com might need to keep those old hashers around, many projects will need it as well. As such, providing the hashers in a dedicated "legacy" package might be the solution for most projects. For the deprecation process, I think the needs of most

Re: Bringing some popular must have django tools/packages under django org umbrella

On Wed, 16 Mar 2016 15:39:40 +0100 James Pic wrote: > On Wed, Mar 16, 2016 at 3:22 PM, Matías Iturburu wrote: > > Even if I submit a patch I wouldn't be able to: > > - Merge it into mainline. > > - Upload the patched version to pypi. > > > > So it's a

Re: Making Django more PaaS-friendly

Hi James, >From the experience on our projects, the ``CONFIG.getstr('db.password')`` >format works well in settings files: - It makes it clear that this field is loaded from the environment, and what type is expected - The setting is set and loaded in the same place - It allows for type

Re: standardised approach for packaged apps to define default settings

Hello, On this topic, I'm using the excellent django-appconf library (https://pypi.python.org/pypi/django-appconf), which: - Supports namespaced custom settings - Handles default values natively As far as I can tell, that solution is pretty efficient without requiring specific Django support

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

Hi Pascal, I'm unsure as to what problem you're trying to solve; if I understand correctly, this project aims at making a "new" Django behave like an "old" one. I see a few possible use cases in the conversation: * Running a legacy application (without new development) beyond the upstream

Re: automating Django releases

On Fri, 25 Nov 2016 11:49:54 -0800 (PST) Tim Graham wrote: > After doing releases about once a month for a while, I'm thinking it would > be nice if releasing Django could be a bit more automated. As far as I > know, the process hasn't changed too much in 10 years, while

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

On Wed, 16 Nov 2016 20:32:34 -0800 (PST) Yo-Yo Ma wrote: > I'm not a fan of adding more complexity, for a couple reasons: > > 1) you have the ['*'] option for local / office development > 2) you can just add a record to /etc/hosts to point to the server and then > use

Re: Guidelines to name python modules of Django applications?

If I understand correctly the input, would the following proposal be an acceptable middle ground? Replace: > It’s often useful to prepend django- to your module name when creating a > package to distribute. This helps others > looking for Django apps identify your app as Django specific With: