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 ;)
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
sup
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:
>
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 the state of
> Python
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 a name like e.g., local-of
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 checking
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 no-starter,
> > I can't rely on my fork, not
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 sit
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 muc
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 people in the thread)
or 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 cast it back".
Regards,
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 dicts
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 other than
> > > auth.U
13 matches
Mail list logo