Why would you call them magic?
Why does allowing extensibility for those who need it is a bad idea?
You will be doing it explicitly anyway by providing a SettingsCollector
class to the Settings class' constructor.
If are doing it, you should know what you are doing.
. Is my code harder to debug or
On Fri, Mar 15, 2013 at 3:36 PM, Omer Katz wrote:
> Why would you call them magic?
> Why does allowing extensibility for those who need it is a bad idea?
> You will be doing it explicitly anyway by providing a SettingsCollector
> class to the Settings class' constructor.
> If are doing it, you sh
Doesn't the fact that the patch makes the code clearer is a reason enough
for a merge (providing that there will be tests attached to it and
documentation)?
I guess that for a complex project like Django it might not but I still see
value in this patch for that reason alone.
Well, if you are wri
By the way,
The fact that I mentioned that this patch can be extended to load packages
as well doesn't mean it's the only use case.
I asked you guys if you think that this is needed.
It will enable you to split settings as packages per deployment
(development package, staging package, production
Omer,
To convince the core committers that the patch is valuable, you need to show
how it improves things. Build examples for the use-cases mentioned in the
thread, show how they would be done without your patch, and how the presence
of your patch allows improvements. The main argument against
On 15 mars 2013, at 09:22, Omer Katz wrote:
> Doesn't the fact that the patch makes the code clearer is a reason enough for
> a merge (providing that there will be tests attached to it and documentation)?
Hi Omer,
This patch isn't only a refactoring; it adds a new feature. Otherwise you
woul
On Mon, Mar 11, 2013 at 2:50 PM, Tom Evans wrote:
> Hi all
>
> Someone just asked on users@ "How do I reverse a URL inside
> settings.py". I gave a solution (eventually; got it wrong the first
> time!) using two functions from django.utils.functional, lazy() and
> memoize().
>
> Neither of these t
Hi Tom,
On Friday, March 15, 2013 12:11:04 PM UTC+1, Tom Evans wrote:
>
> Any thoughts on this please?
>
What's wrong with the solution provided by Donald, which is already in core?
Regards,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django develop
My organization just hit a use case where we need MS-SQL support.
I am jumping on board, so there are at least two of us who can do
maintenance.
I must say that I would prefer quasi-supported status (akin to admin
and geodjango) rather than actually being in the core. I think it would
be a
