Re: Changes to django's settings module

Hi Omer - OK, I think it's time for you to drop this. Thanks for your suggestions, but we're not going to be adding this to Django. Jacob On Sun, Mar 24, 2013 at 9:32 AM, Omer Katz wrote: > 2013/3/24 Russell Keith-Magee >> >> >> On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz wrote: >>> >>> You ar

Re: Changes to django's settings module

My name is Om*e*r and got it. :) 2013/3/24 Albert O'Connor > Hey Omar, > > Though it may be clear now from this experience, I feel your expectations > about how code becomes a part of Django were incorrect, leading to > some frustration. > > The onus is on the contributor not the core committer

Re: Changes to django's settings module

2013/3/24 Russell Keith-Magee > > On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz wrote: > >> You are contradicting yourself. At first you said that it does make the >> code clearer. Now you say it doesn't. >> > > My apologies -- I've apparently used an English idiom that doesn't have an > obvious me

Re: Changes to django's settings module

Hey Omar, Though it may be clear now from this experience, I feel your expectations about how code becomes a part of Django were incorrect, leading to some frustration. The onus is on the contributor not the core committers for nearly all aspects of making a contribution, which is likely a differ

Re: Changes to django's settings module

On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz wrote: > You are contradicting yourself. At first you said that it does make the > code clearer. Now you say it doesn't. > My apologies -- I've apparently used an English idiom that doesn't have an obvious meaning. When I said "I'd argue the point that

Re: Changes to django's settings module

You are contradicting yourself. At first you said that it does make the code clearer. Now you say it doesn't. Ok, you guys are right. I'm adding a new feature. If you think my new design isn't good enough do tell me why. I'll improve it/change it completely. It now doesn't violate SRP, it allows fl

Re: Changes to django's settings module

Hi Omer, I've looked at your code, and while you continue to call it a "refactoring", it's a refactoring with a specific purpose in mind -- to add a new feature. I disagree that your new code is "clearer" and more "understandable" than the existing code. For starters, it's got more moving parts (

Re: Changes to django's settings module

So is my example good enough? Have you tried using it? בתאריך יום שישי, 15 במרץ 2013 13:17:11 UTC+3, מאת Aymeric Augustin: > > 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

Re: Changes to django's settings module

Well, I was wrong. It took me exactly 5 minutes to get the basics of django-configurations right: https://gist.github.com/thedrow/5180120 This gist loads settings from a class instead of a module and shows how to load the settings from a module and override them by using a class. All tests run corr

Re: Changes to django's settings module

Shai, The google groups editor is kinda annoying. I'll be using GMail from now on because it removes formatting on random basis (I don't really know why) Also, I can rewrite django-configuartion in a couple of hours using the changes in this patch. Heck, I'll even make a pull request out of it. A

Re: Changes to django's settings module

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

Re: Changes to django's settings module

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

Re: Changes to django's settings module

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

Re: Changes to django's settings module

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

Re: Changes to django's settings module

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

Re: Changes to django's settings module

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

Re: Changes to django's settings module

All of the changes you describe are what I would call "magic". Magic has a downside: it's hard to understand and debug. As it currently stands, Django has exactly one form of settings magic: there is a DJANGO_SETTINGS_MODULE environment variable that adjusts where the settings are found. This is ea

Re: Changes to django's settings module

Also don't you guys think that the SettingsCollector class will simplify the implementation of django-configurations for example? בתאריך יום רביעי, 13 במרץ 2013 19:27:02 UTC+3, מאת Omer Katz: > > Lately I implemented some changes for django's settings module . > I refactored the whole module in o

Re: Changes to django's settings module

You haven't referred to the pull request. The pull request itself currently just refactors the settings module in order to have better extensiblity hooks and to clarify the code. The pull request introduced the SettingsCollector class which allows you

Re: Changes to django's settings module

Yeah, settings is more about the environments than the framework. There is not a single solutions that can make everyone happy. I'd say whatever works for you is the best solution for you. With that said, I also agree that a few good examples would be very beneficial to people new to Django. Val

Re: Changes to django's settings module

On 14 mars 2013, at 15:43, Alex Ogier wrote: > I don't know if there is a good way to document these practices -- it's not > an easily searchable topic, and more than a single settings.py is just added > confusion for little benefit until you need to care about deploying to > multiple contexts

Re: Changes to django's settings module

I think the important point is that all of these techniques for constructing settings are done without the help of Django (and in fact *should* be done without the help of Django, because some parts of Django expect to import a settings module that isn't under construction). I don't know if there i

Re: Changes to django's settings module

Yeah, split by role is what I have done. settings/default.py (absolute necessities) settings/deploy.py (inherits default.py & adds production specifics) settings/debug.py (inherits deploy.py & overwrites debug stuff) settings/test.py (inherits deploy.py & overwrites test specific) settings/externa

Re: Changes to django's settings module

On Thu, Mar 14, 2013 at 1:08 AM, Alex Ogier wrote: > I find the value of separate settings modules is not splitting them by > topic, but overriding them in specific contexts, like staging, production > and development. Your implementation (and, I think, any solution that > compiles multiple setti

Re: Changes to django's settings module

I find the value of separate settings modules is not splitting them by topic, but overriding them in specific contexts, like staging, production and development. Your implementation (and, I think, any solution that compiles multiple settings modules independently) don't have a way to specify orderi

Changes to django's settings module

Lately I implemented some changes for django's settings module . I refactored the whole module in order to have more extension points. With #20040 it is now possible to inject the Settings class that will be used by the LazySettings object and I intro