Re: Persistent connections, take 2
On Monday 18 March 2013, Aymeric Augustin wrote: > On 18 mars 2013, at 17:10, Shai Berger wrote: > > If the persistent connections are thread-local, don't you want to close > > them anyway when the thread exits? > > Yes, do you know how this could be achieved? I haven't found how to hook > on thread termination. > You can get a list of the "living" threads from threading.enumerate(), so it is possible to find out that a thread has already ended. This probably quite inefficient, but may be good enough for runserver. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why not switch hasher when number of iterations changes?
Wonderful, thank you! On Mon, Mar 18, 2013 at 10:59 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 18 mars 2013, at 21:51, Ram Rachum wrote: > > > Why does Django switch to the new hasher only if the algorithm was > changed, and not if the number of iterations (which could be critical) > changed? > > See https://code.djangoproject.com/ticket/19043. > > -- > Aymeric. > > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/0MYBpHOyZGE/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why not switch hasher when number of iterations changes?
On 18 mars 2013, at 21:51, Ram Rachum wrote: > Why does Django switch to the new hasher only if the algorithm was changed, > and not if the number of iterations (which could be critical) changed? See https://code.djangoproject.com/ticket/19043. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Why not switch hasher when number of iterations changes?
Look at this code: https://github.com/django/django/blob/master/django/contrib/auth/hashers.py#L55 Why does Django switch to the new hasher only if the algorithm was changed, and not if the number of iterations (which could be critical) changed? Thanks, Ram. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent connections, take 2
On 18 maalis, 19:01, Aymeric Augustin wrote: > On 18 mars 2013, at 17:10, Shai Berger wrote: > > > If the persistent connections are thread-local, don't you want to close them > > anyway when the thread exits? > > Yes, do you know how this could be achieved? I haven't found how to hook > on thread termination. > > > ... but that fix will kill persistent connections under gunicorn. > > If you're talking of gunicorn + gevent, persistent connections simply cannot > work, so this doesn't matter as long as Django doesn't use more database > connections than "live" threads. > > > The solution that sounds "right" is to pool the persistent connections -- > > every thread that ends returns the connection to the pool. > > Yes, using an external pooler is the right solution in cases where persistent > connections don't work. It is possible to create a pool of connections to reuse inside Django. Close releases back to pool, get_new_connection() fetches an unused connection from the pool or creates a new connection if none available. The downside is that having a real connection pool is necessarily more complex than the current setup. The problematic cases are how to deal with `__del__` and plain concurrency can cause problems, too. However a real pool would solve the above problems and thus it would be possible to default persistent connections to on. The needed amount of code is 100-200 LOC for the as-simple-as-possible pool. For now I would just default the persistent connections feature to off. I believe most Django projects fall into category where connection creation performance doesn't matter. For those projects where connection creation performance does matter turning persistent connection on is easy enough. The default can be changed later on if need be. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent connections, take 2
On 18 mars 2013, at 17:10, Shai Berger wrote: > If the persistent connections are thread-local, don't you want to close them > anyway when the thread exits? Yes, do you know how this could be achieved? I haven't found how to hook on thread termination. > ... but that fix will kill persistent connections under gunicorn. If you're talking of gunicorn + gevent, persistent connections simply cannot work, so this doesn't matter as long as Django doesn't use more database connections than "live" threads. > The solution that sounds "right" is to pool the persistent connections -- > every thread that ends returns the connection to the pool. Yes, using an external pooler is the right solution in cases where persistent connections don't work. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?
Hi,
Reviving an oldish thread:
On Tuesday 26 February 2013 00:35:10 Florian Apolloner wrote:
> it would be of great help
> if you could setup cx_Oracle on an Ubuntu 11.10 (I have to double check
> that tomorrow, don't have my ssh keys with me currently) 64 bit system with
> python 3.3 and see if you can get the tests running or if you also get a
> segfault.
>
I got as far as performing a simple query, no segfault. As I'm writing this,
I'm downloading the Django sources to the Ubuntu 11.10 VM in order to try
running the tests.
As far as I know, I did nothing special for this -- just compiled Python from
source, unzipped the instantclient packages, and used them to build cx_Oracle
from source in a Python3 virtual environment ("pyvenv").
Hope this is still of interest,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent connections, take 2
On Monday 18 March 2013 16:36:53 Aymeric Augustin wrote: > By default, the development server creates a new thread for each request it > handles. Not only does this negate the effect of persistent connections > (they're thread-local), > [...] > 1) Do we want to enable persistent connections in production by default? > > 2) Assuming the answer to 1) is yes, can we fix runserver? > a) close connections at the end of the dev server request handler > => creates tight coupling between the dev server and the ORM :( > b) disable persistent connections when DEBUG = True > => badly targeted: some people may use runserver with DEBUG = > False, > or want persistent connections when DEBUG = True > c) ??? > If the persistent connections are thread-local, don't you want to close them anyway when the thread exits? > Florian independently discovered the same problem with gunicorn + gevent, > because the gevent worker runs each request in its own "thread" > (greenlet). ... but that fix will kill persistent connections under gunicorn. The solution that sounds "right" is to pool the persistent connections -- every thread that ends returns the connection to the pool. If I understand correctly, this would tie the ORM not to the dev server, but to the wsgi handler -- but in a sense where, actually, it should be tied. Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent connections, take 2
It sounds like we need a way to tell the worker that we are done sending requests to it so that the worker can do cleanup (of which db conn close is one task). This mirrors the previous request_finished "coupling" to requests_finished. (OS?) Signal? Sentinel queue/socket/named pipe + background thread? On Mar 18, 2013, at 7:36 AM, Aymeric Augustin wrote: > On 28 févr. 2013, at 00:12, Aymeric Augustin > wrote: > >> I'm just wondering if 10 minutes is a good default value for CONN_MAX_AGE. > > > Since I committed the patch, I discovered that persistent connections don't > interact well with runserver. > > By default, the development server creates a new thread for each request it > handles. Not only does this negate the effect of persistent connections > (they're thread-local), but it also keeps connections open until they're > garbage collected, making it easy to exceed the maximum number of available > connections. > > Florian independently discovered the same problem with gunicorn + gevent, > because the gevent worker runs each request in its own "thread" (greenlet). > > > This raises the following questions: > > 1) Do we want to enable persistent connections in production by default? >a) yes >b) yes, through a deprecation path >c) no > > 2) Assuming the answer to 1) is yes, can we fix runserver? >a) close connections at the end of the dev server request handler >=> creates tight coupling between the dev server and the ORM :( >b) disable persistent connections when DEBUG = True >=> badly targeted: some people may use runserver with DEBUG = False, > or want persistent connections when DEBUG = True >c) ??? > > > The lazy solution is to disable persistent connections by default, document > the problem with servers that run each request in its own thread, and > recommend to set `DATABASES['default']['CONN_MAX_AGE'] = 0 if settings.DEBUG > else 600`. > > Besides, I've observed that performance is often less of a concern that > backwards-compatibility and ease of use; from this perspective, disabling > persistent connections would be appropriate. > > > What do you think? > > -- > Aymeric. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: URL dispatcher fallthrough?
Hi Julian, On Mon, 18 Mar 2013, julianb wrote: imagine the following use case: You build an online store where you have sorted products into several categories and maybe associated an occasion. Now you want to build URLs. So the URL schema that all of the store's owners agree on is: // // // Look simple. Because product slugs should generally be different to category slugs and occasions, you expect no clashes here. And you don't want to bloat the URLs by putting product/ and category/ in there. And you also do not want to resort making it look cryptic by having just /p// and so on. Then it comes to Django. How do you do that? I put the type in the URL to make it obvious. That doesn't harm SEO and makes your URL routing clearer. For example: /product// /category// /occasion// But that's getting into django-users territory. Cheers, Chris. -- Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK Aptivate is a not-for-profit company registered in England and Wales with company number 04980791. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: URL dispatcher fallthrough?
Hi, Julian I think this problem can already be addressed by having a single catchall // URL pattern, and writing a SlugHandlerView which would try different options within the view code, rather than in the URL dispatching. Then it would just be a matter or catching exceptions for your .get() methods, and raising a final 404 in case nothing is found, which would in turn make this a django-users sort of question from here on. Unless I'm missing something, this behavior can be achieved with what's already in core today. Cheers, AT On Mon, Mar 18, 2013 at 12:23 PM, julianb wrote: > Hi, > > imagine the following use case: > > You build an online store where you have sorted products into several > categories and maybe associated an occasion. Now you want to build URLs. So > the URL schema that all of the store's owners agree on is: > > // > // > // > > Look simple. > > Because product slugs should generally be different to category slugs and > occasions, you expect no clashes here. And you don't want to bloat the URLs > by putting product/ and category/ in there. And you also do not want to > resort making it look cryptic by having just /p// and so on. > Then it comes to Django. How do you do that? > > Well, at the moment, as far as I am aware, you can't. The first URL will > match everything all the time, not giving the other views a chance to kick > in. > > So I propose some kind of URL fallthrough. The view could do > > raise UrlNotMatched > > and the dispatcher goes to the next possible matching view. > > Would that be good? Any thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: URL dispatcher fallthrough?
The approach we take at work is to have a view that wraps around the product, category and occasion views and takes care of the fallthrough logic. I'm not a fan of this approach, because it means that you can't just look at the urlconf and see which pattern maps to which view function. On the other hand, I don't think your solution would solve this either, you'd end up having 3 patterns that could all match, making it non-obvious what the behaviour is. Obviously the ideal solution is to scope URLs correctly to avoid all this in the first place, but I've found that in the real world this is easier said than done. So it would be nice to have an idiomatic solution. An alternative might be a kwarg on the url function, such as 'fallthrough_on_404'. But it all feels a bit hackish to me :/ Regards, Andy On 18 March 2013 15:23, julianb wrote: > Hi, > > imagine the following use case: > > You build an online store where you have sorted products into several > categories and maybe associated an occasion. Now you want to build URLs. So > the URL schema that all of the store's owners agree on is: > > // > // > // > > Look simple. > > Because product slugs should generally be different to category slugs and > occasions, you expect no clashes here. And you don't want to bloat the URLs > by putting product/ and category/ in there. And you also do not want to > resort making it look cryptic by having just /p// and so on. > Then it comes to Django. How do you do that? > > Well, at the moment, as far as I am aware, you can't. The first URL will > match everything all the time, not giving the other views a chance to kick > in. > > So I propose some kind of URL fallthrough. The view could do > > raise UrlNotMatched > > and the dispatcher goes to the next possible matching view. > > Would that be good? Any thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
URL dispatcher fallthrough?
Hi, imagine the following use case: You build an online store where you have sorted products into several categories and maybe associated an occasion. Now you want to build URLs. So the URL schema that all of the store's owners agree on is: // // // Look simple. Because product slugs should generally be different to category slugs and occasions, you expect no clashes here. And you don't want to bloat the URLs by putting product/ and category/ in there. And you also do not want to resort making it look cryptic by having just /p// and so on. Then it comes to Django. How do you do that? Well, at the moment, as far as I am aware, you can't. The first URL will match everything all the time, not giving the other views a chance to kick in. So I propose some kind of URL fallthrough. The view could do raise UrlNotMatched and the dispatcher goes to the next possible matching view. Would that be good? Any thoughts? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Persistent connections, take 2
On 28 févr. 2013, at 00:12, Aymeric Augustin wrote: > I'm just wondering if 10 minutes is a good default value for CONN_MAX_AGE. Since I committed the patch, I discovered that persistent connections don't interact well with runserver. By default, the development server creates a new thread for each request it handles. Not only does this negate the effect of persistent connections (they're thread-local), but it also keeps connections open until they're garbage collected, making it easy to exceed the maximum number of available connections. Florian independently discovered the same problem with gunicorn + gevent, because the gevent worker runs each request in its own "thread" (greenlet). This raises the following questions: 1) Do we want to enable persistent connections in production by default? a) yes b) yes, through a deprecation path c) no 2) Assuming the answer to 1) is yes, can we fix runserver? a) close connections at the end of the dev server request handler => creates tight coupling between the dev server and the ORM :( b) disable persistent connections when DEBUG = True => badly targeted: some people may use runserver with DEBUG = False, or want persistent connections when DEBUG = True c) ??? The lazy solution is to disable persistent connections by default, document the problem with servers that run each request in its own thread, and recommend to set `DATABASES['default']['CONN_MAX_AGE'] = 0 if settings.DEBUG else 600`. Besides, I've observed that performance is often less of a concern that backwards-compatibility and ease of use; from this perspective, disabling persistent connections would be appropriate. What do you think? -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
GeoDjango International Date Line (IDL) handling
My previous email got messed up (ended up in a different thread), so I am sending again. -- If you build a geom with a bounding box that contains IDL (International Date Line) and run a point__within query on it, then the result is unpredictable and incorrect. Does anyone know of a native GeoDjango solution to this? If not, should I create a patch that incorporates this functionality in GeoDjango? Or handling of IDL in the above case would be considered not within the scope of the framework? Thanks, Val -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: GeoDjango and __within query when IDL is involved
I must have hit reply on my iPhone instead of new email. Not meant to be a response to your email. Sorry about the confusion. Sent from my iPad On Mar 18, 2013, at 5:40 AM, Omer Katz wrote: > Sorry, how is this related? > > בתאריך יום ראשון, 17 במרץ 2013 19:34:53 UTC+3, מאת Val Neekman: >> >> If you build a geom with a bounding box that contains IDL (International >> Date Line) and run a point__within query on it, then the result is >> unpredictable and incorrect. >> >> Does anyone know of a native GeoDjango solution to this? >> >> If not, would there be a lot of resistance against a patch that incorporates >> this functionality in GeoDjango? >> >> >> Val >> Sent from my mobile device. >> >> On 2013-03-17, at 12:39 AM, Omer Katz wrote: >> >>> 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 correctly. >>> Are you guys still not convinced? >>> >>> >>> 2013/3/16 Omer Katz 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. Aymeric, I can revert this patch to be a refactoring if we decide that we don't see any value in the extensibility part of this patch. I hope we all agree that this patch does make the code much clearer and understandable. I'll get back to you guys when I'll have more progress. 2013/3/15 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 be tests attached to it > > and documentation)? > > > Hi Omer, > > This patch isn't only a refactoring; it adds a new feature. Otherwise you > wouldn't be talking about documentation. > > Each feature added to Django creates a burden: > - for users of Django, who must learn to use it; > - for the core team, who must maintain it for the foreseeable future. > > To be accepted, a new feature must: > (a) provide benefits that clearly outweigh these costs > (b) not get in the way of future improvements — as much as can be > foreseen. > > Unfortunately (a) the benefits of your PR still aren't clear and (b) > judging by the discussion, your abstraction doesn't match very well the > needs of most users, and I suspect it could hinder further efforts to > make per-environment settings (the actual problem) easier to define. > > -- > Aymeric. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/1M5nfnpba0M/unsubscribe?hl=en. > To unsubscribe from this group and all its topics, send an email to > django-develop...@googlegroups.com. > To post to this group, send email to django-d...@googlegroups.com. > Visit this group at > http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit http
Re: GeoDjango and __within query when IDL is involved
Sorry, how is this related? בתאריך יום ראשון, 17 במרץ 2013 19:34:53 UTC+3, מאת Val Neekman: > > If you build a geom with a bounding box that contains IDL (International > Date Line) and run a point__within query on it, then the result is > unpredictable and incorrect. > > Does anyone know of a native GeoDjango solution to this? > > If not, would there be a lot of resistance against a patch that > incorporates this functionality in GeoDjango? > > > Val > Sent from my mobile device. > > On 2013-03-17, at 12:39 AM, Omer Katz > > wrote: > > 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 correctly. > Are you guys still not convinced? > > > 2013/3/16 Omer Katz > > >> 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. >> >> Aymeric, >> I can revert this patch to be a refactoring if we decide that we don't >> see any value in the extensibility part of this patch. >> I hope we all agree that this patch does make the code much clearer and >> understandable. >> >> I'll get back to you guys when I'll have more progress. >> >> >> 2013/3/15 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 be tests attached to it and >>> documentation)? >>> >>> >>> Hi Omer, >>> >>> This patch isn't only a refactoring; it adds a new feature. Otherwise >>> you wouldn't be talking about documentation. >>> >>> Each feature added to Django creates a burden: >>> - for users of Django, who must learn to use it; >>> - for the core team, who must maintain it for the foreseeable future. >>> >>> To be accepted, a new feature must: >>> (a) provide benefits that clearly outweigh these costs >>> (b) not get in the way of future improvements — as much as can be >>> foreseen. >>> >>> Unfortunately (a) the benefits of your PR still aren't clear and (b) >>> judging by the discussion, your abstraction doesn't match very well the >>> needs of most users, and I suspect it could hinder further efforts to make >>> per-environment settings (the actual problem) easier to define. >>> >>> -- >>> Aymeric. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Django developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/django-developers/1M5nfnpba0M/unsubscribe?hl=en >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> django-develop...@googlegroups.com . >>> To post to this group, send email to >>> django-d...@googlegroups.com >>> . >>> Visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-develop...@googlegroups.com . > To post to this group, send email to django-d...@googlegroups.com > . > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
