Hello Christopher, On 02/08/2013 09:59 AM, Christopher Medrela wrote: > I don't want to discourage you from working on the project if you find > > it interesting and informative, and it may well be that the results are > > worth the effort and end up being merged into Django; but it is also > > possible that we look at the patch and say "sorry, that's just too much > > disruption for the benefits" - so you should be prepared for that > > possibility. > > > I would like to avoid the situation like that, so what is the source of > that disruption, apart from backward incompatibility?
There are always risks associated with major codebase churn - both unanticipated backwards-incompatibilities, and introducing new bugs. We have to make sure the benefits of the change outweigh those risks. > I agree that it doesn't mean less global state. But there is good global > state and bad global state. For example, we could make DjangoApplication > class to avoid global state but there is no need. Global settings is OK > since we don't need the ability to create more than one django > application instance. Even tests doesn't require more than one instance > at the same time, so we can just reinitialize the application when there > is need for that. That's done by change_settings decorator and it works > well. And there is bad global state, like current template system. ... > I didn't know about Jinja2 and that it's more suitable for use outside > Django. So it seems like the only goal is refactoring -- we need to > quarantize global state, but not dependencies on settings. We also don't > need to split the template system into django-dependent and > django-independent parts. I'm not sure the distinction between "good global state" and "bad global state" is so clear, or even exists. A major part of the motivation for #17093 was that it could be a step along the path towards a global-state-free Django (using something like a DjangoApplication or ApplicationConfig object), which would allow running multiple Django sites in a single process (which is indeed something that some people, though not most, need). This is mentioned in the ticket description. If we are not working towards that larger goal (and I'd love to hear other opinions on whether we should be or not), and external library use of Django templates is not a strong motivator, and the testing issues are manageable via override_settings, then I think the rationale for #17093 begins to look rather weak. No-global-state would be a better from-scratch design, certainly, but will it bring enough concrete benefit now to be worth the transition? > Now I have an idea that we can refactor the template system so it will > be possible to easily write and use other template systems, for example > Mako. So anyone will be able to write "custom_engine = > MakoTemplateEngine()" in settings (or anywhere else). Next, we can type > "render_to_response(engine=custom_engine, ...)" or something like that. ... > If we refactor the code properly, class-based views will work with Mako > templates. That would be huge advantage over existing solutions like > django-mako. I think that could be a good idea for GSoC this year. Do > you think so? This definitely would bring some value; it's the best rationale I see for refactoring the template engine. Carl -- 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.
