Re: Session/cookie based messages (#4604)

[David Cramer]

I'm with Luke on this for the exact reasons he describes.

Sent from my iPhone

On Dec 5, 2009, at 7:24 PM, Russell Keith-Magee
 wrote:

> On Sun, Dec 6, 2009 at 10:28 AM, Luke Plant 
> wrote:
>> On Sunday 06 December 2009 00:56:56 Russell Keith-Magee wrote:
>>
 Really?  Files definitely seem to be more on the "storage" side
 of things:

 http://code.djangoproject.com/browser/django/trunk/django/core/fi
 les/storage.py
>>>
>>> The problem we have here is that we have all sorts of
>>>  inconsistencies introduced by history. Yes, files and templates
>>>  use function/class level specifiers, but db, session, cache, and
>>>  email all use module level specifiers. Module level specifiers
>>>  have the majority at this point, and personally, I prefer the
>>>  module approach - it shortens the user configuration strings, and
>>>  it enforces good usage of modules.
>>
>> I would have to question "enforcing good usage of modules"!  It
>> enforces a *single* way of using modules, that is, one class per
>> module.
>
> The fact that it is one class per module is, IMHO, incidental. It's
> one *concept* per module - one *backend* per module that I consider to
> be a design pattern worth enforcing.
>
>>  That is not necessarily 'good', it certainly isn't Pythonic
>> in my experience, and it could well be bad. As such, it would be
>> opinionated in a bad way - it forces other developers to have a
>> proliferation of modules which might be very inconvenient.  Why not
>> just leave the decision in the hands of the people who are writing
>> and
>> organizing the code? We are all consenting adults here.
>
> The only time I can see this as inconvenient is if you want to put two
> backends in the same module - to which I say you should have two
> modules anyway.
>
> A part of my like for modules is the aesthetic of the end settings:
>
> BACKEND = 'path.to.module.backends.cookie.CookieBackend'
>
> vs
>
> BACKEND = 'path.to.module.backends.cookie'
>
> I vastly prefer the latter for the duplication it avoids.
>
>> In addition to the arguments in my other message, you also have the
>> case where some third party writes a backend, and then realises they
>> need another. So, they had:
>>
>> acme.messages.MessageStorage
>>
>> and just want to add
>>
>> acme.messages.SuperMessageStorage
>>
>> Instead, they are forced to move code around so each of these can
>> live
>> in its own module, or else have stub modules that serve no purpose
>> except to appease the Django-gods.
>
> Again, I call this good code modularity. It may well be that the
> second module requires nothing but an import and a configuration of
> the first, but I would still argue that it would be good practice to
> use two modules.
>
>> I agree that it would be good to be consistent if possible, but I
>> would also like to see the better convention used, and the e-mail
>> system could just as easily be changed as the messages system at this
>> point, which would swing the majority the other way (it's actually
>> currently "4-all" by my count, and that doesn't include the other
>> configurable callables and classes, such as TEST_RUNNER,
>> CSRF_FAILURE_VIEW, context processors, middlewares and view
>> functions,
>> which all use full paths). And #6262 could also go the other way too.
>
> I'm not sure I pay the comparison with middlewares, context processors
> and the like. A middleware is, by definition, just a class. Off the
> top of my head, I can't think of any examples where a middleware
> module is split into submodules - most apps just define a middleware
> module and put all relevant middlewares in that module. Hence, there
> is no namespace duplication.
>
> On the other hand, backends are consistently broken into submodules,
> because they're a lot more complex. The backend isn't defined by a
> single class - conceptually, there's can be multiple classes, support
> data structures, etc. The database backends are the best demonstration
> of this, but IMHO the broader concept exisis and is worth preserving
> in other backends.
>
> However, I'm also willing to admit that personal preference is a
> factor here. We may just need to push this up for a BDFL judgement. I
> would certainly prefer module level definitions, but at the end of the
> day, I don't think I'd lose much sleep if the decision went the other
> way.
>
> Yours,
> Russ Magee %-)
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com
> .
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en
> .
>
>

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to 

Re: Session/cookie based messages (#4604)

[Russell Keith-Magee]

On Sun, Dec 6, 2009 at 10:28 AM, Luke Plant  wrote:
> On Sunday 06 December 2009 00:56:56 Russell Keith-Magee wrote:
>
>> > Really?  Files definitely seem to be more on the "storage" side
>> > of things:
>> >
>> > http://code.djangoproject.com/browser/django/trunk/django/core/fi
>> >les/storage.py
>>
>> The problem we have here is that we have all sorts of
>>  inconsistencies introduced by history. Yes, files and templates
>>  use function/class level specifiers, but db, session, cache, and
>>  email all use module level specifiers. Module level specifiers
>>  have the majority at this point, and personally, I prefer the
>>  module approach - it shortens the user configuration strings, and
>>  it enforces good usage of modules.
>
> I would have to question "enforcing good usage of modules"!  It
> enforces a *single* way of using modules, that is, one class per
> module.

The fact that it is one class per module is, IMHO, incidental. It's
one *concept* per module - one *backend* per module that I consider to
be a design pattern worth enforcing.

>  That is not necessarily 'good', it certainly isn't Pythonic
> in my experience, and it could well be bad. As such, it would be
> opinionated in a bad way - it forces other developers to have a
> proliferation of modules which might be very inconvenient.  Why not
> just leave the decision in the hands of the people who are writing and
> organizing the code? We are all consenting adults here.

The only time I can see this as inconvenient is if you want to put two
backends in the same module - to which I say you should have two
modules anyway.

A part of my like for modules is the aesthetic of the end settings:

BACKEND = 'path.to.module.backends.cookie.CookieBackend'

vs

BACKEND = 'path.to.module.backends.cookie'

I vastly prefer the latter for the duplication it avoids.

> In addition to the arguments in my other message, you also have the
> case where some third party writes a backend, and then realises they
> need another. So, they had:
>
> acme.messages.MessageStorage
>
> and just want to add
>
> acme.messages.SuperMessageStorage
>
> Instead, they are forced to move code around so each of these can live
> in its own module, or else have stub modules that serve no purpose
> except to appease the Django-gods.

Again, I call this good code modularity. It may well be that the
second module requires nothing but an import and a configuration of
the first, but I would still argue that it would be good practice to
use two modules.

> I agree that it would be good to be consistent if possible, but I
> would also like to see the better convention used, and the e-mail
> system could just as easily be changed as the messages system at this
> point, which would swing the majority the other way (it's actually
> currently "4-all" by my count, and that doesn't include the other
> configurable callables and classes, such as TEST_RUNNER,
> CSRF_FAILURE_VIEW, context processors, middlewares and view functions,
> which all use full paths). And #6262 could also go the other way too.

I'm not sure I pay the comparison with middlewares, context processors
and the like. A middleware is, by definition, just a class. Off the
top of my head, I can't think of any examples where a middleware
module is split into submodules - most apps just define a middleware
module and put all relevant middlewares in that module. Hence, there
is no namespace duplication.

On the other hand, backends are consistently broken into submodules,
because they're a lot more complex. The backend isn't defined by a
single class - conceptually, there's can be multiple classes, support
data structures, etc. The database backends are the best demonstration
of this, but IMHO the broader concept exisis and is worth preserving
in other backends.

However, I'm also willing to admit that personal preference is a
factor here. We may just need to push this up for a BDFL judgement. I
would certainly prefer module level definitions, but at the end of the
day, I don't think I'd lose much sleep if the decision went the other
way.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Tests blocked by AssertionError 200 != 302 in login() calls

[Gordon A]

On Dec 5, 7:06 pm, Russell Keith-Magee  wrote:
> It's unclear if you're in the right place. Django-dev is for
> discussing the development of Django itself; django-users is for
> general user queries. Generally, if you're unsure, django-users is the
> right place to start.

Whoops.  Sorry.



> You haven't given specific details of exactly which tests are failing,
> but I suspect you're talking about the contrib.auth tests.

Yes.

> If password change tests are failing, it suggests that you have done
> something to change the way passwords are validated, and that change
> isn't compatible with Django. However, it's impossible to know what is
> going wrong without more details on exactly what you have done.

Yes, I'd written settings.py to take authentication from Apache2, and
your
answer is an important hint.  When I commented out my setting for
AUTHENTICATION_BACKEND setting, the tests ran fine.  I suppose that
should make me think about the state of authentication in my test
environment,
but I'll take any questions over to django-users.

Thanks very much for your help.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: smart if tag

[Luke Plant]

On Saturday 05 December 2009 20:09:21 Luke Plant wrote:

> I'm not likely to able to look at this before Tuesday.  If anyone
> wants to look at it, I think the right approach is something like
>  the following:
> http://effbot.org/zone/simple-top-down-parsing.htm
> (without the globals, obviously, they can be converted to instance
> variables/methods).

Cancel that - I unexpectedly had free time this evening, and I 
implemented this.  It's a nice replacement I think (credit to Vaughan 
Pratt and Fredrik Lundh for the basic approach and Python 
implementation respectively).  The new implementation is pretty much 
the same length as the old one, and hopefully easier to read, with a 
much smaller core parser.  Precedence is specified directly, rather 
than implicitly, so it's much easier to check that it's the same as 
Python's.

Latest patch attached to this e-mail.

Regards,

Luke

-- 
"Idiocy: Never underestimate the power of stupid people in large 
groups." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.


diff -r 70e75e8cd224 django/template/defaulttags.py
--- a/django/template/defaulttags.py	Thu Dec 03 15:11:14 2009 +
+++ b/django/template/defaulttags.py	Sun Dec 06 01:04:04 2009 +
@@ -11,6 +11,7 @@
 from django.template import Node, NodeList, Template, Context, Variable
 from django.template import TemplateSyntaxError, VariableDoesNotExist, BLOCK_TAG_START, BLOCK_TAG_END, VARIABLE_TAG_START, VARIABLE_TAG_END, SINGLE_BRACE_START, SINGLE_BRACE_END, COMMENT_TAG_START, COMMENT_TAG_END
 from django.template import get_library, Library, InvalidTemplateLibrary
+from django.template.smartif import IfParser, Literal
 from django.conf import settings
 from django.utils.encoding import smart_str, smart_unicode
 from django.utils.itercompat import groupby
@@ -227,10 +228,9 @@
 return self.nodelist_false.render(context)
 
 class IfNode(Node):
-def __init__(self, bool_exprs, nodelist_true, nodelist_false, link_type):
-self.bool_exprs = bool_exprs
+def __init__(self, var, nodelist_true, nodelist_false=None):
 self.nodelist_true, self.nodelist_false = nodelist_true, nodelist_false
-self.link_type = link_type
+self.var = var
 
 def __repr__(self):
 return ""
@@ -250,28 +250,11 @@
 return nodes
 
 def render(self, context):
-if self.link_type == IfNode.LinkTypes.or_:
-for ifnot, bool_expr in self.bool_exprs:
-try:
-value = bool_expr.resolve(context, True)
-except VariableDoesNotExist:
-value = None
-if (value and not ifnot) or (ifnot and not value):
-return self.nodelist_true.render(context)
+if self.var.resolve(context):
+return self.nodelist_true.render(context)
+if self.nodelist_false:
 return self.nodelist_false.render(context)
-else:
-for ifnot, bool_expr in self.bool_exprs:
-try:
-value = bool_expr.resolve(context, True)
-except VariableDoesNotExist:
-value = None
-if not ((value and not ifnot) or (ifnot and not value)):
-return self.nodelist_false.render(context)
-return self.nodelist_true.render(context)
-
-class LinkTypes:
-and_ = 0,
-or_ = 1
+return ''
 
 class RegroupNode(Node):
 def __init__(self, target, expression, var_name):
@@ -761,6 +744,27 @@
 return do_ifequal(parser, token, True)
 ifnotequal = register.tag(ifnotequal)
 
+class TemplateLiteral(Literal):
+def __init__(self, value, text):
+self.value = value
+self.text = text # for better error messages
+
+def display(self):
+return self.text
+
+def resolve(self, context):
+return self.value.resolve(context, ignore_failures=True)
+
+class TemplateIfParser(IfParser):
+error_class = TemplateSyntaxError
+
+def __init__(self, parser, *args, **kwargs):
+self.template_parser = parser
+return super(TemplateIfParser, self).__init__(*args, **kwargs)
+
+def create_var(self, value):
+return TemplateLiteral(self.template_parser.compile_filter(value), value)
+
 #...@register.tag(name="if")
 def do_if(parser, token):
 """
@@ -805,47 +809,21 @@
 There are some athletes and absolutely no coaches.
 {% endif %}
 
-``if`` tags do not allow ``and`` and ``or`` clauses with the same tag,
-because the order of logic would be ambigous. For example, this is
-invalid::
+

Re: Multiple database support: Request for feedback and testing

[Russell Keith-Magee]

On Sun, Dec 6, 2009 at 12:35 AM, Simon Willison  wrote:
> On Dec 5, 4:20 pm, Russell Keith-Magee  wrote:
>> Trust me - I don't want to do mindless busy work. However, we need to
>> have some sort of answer for the admin interface - Django's admin is a
>> big selling point for Django for some people, so we can't really
>> introduce a huge new feature, and then say "but you can't use it in
>> admin". I'm interested in making the least intrusive change that is
>> possible without hamstringing future multi-db interfaces.
>
> It strikes me that the admin issue should be solvable entirely in
> django.contrib.admin without any changes to the multidb code itself.
> Right now you can get most of the job done using a ModelAdmin
> subclass:
>
> from django.contrib import admin
> from blog.models import Entry
>
> class EntryAdmin(admin.ModelAdmin):
>    def save_model(self, request, obj, form, change):
>        obj.save(using='otherdb')
>
>    def queryset(self, request):
>        return Entry.objects.using('otherdb').all()
>
> admin.site.register(Entry, EntryAdmin)
>
> I haven't tested the above so it's probably missing a few cases
> (save_fieldsets for example perhaps) but if we document it I think
> it's a good enough solution for the moment. Even if we need to
> refactor ModelAdmin a bit to ensure the right hooks are available it
> still shouldn't be a massive change.

I want to poke around this code over the next couple of days. I
suspect that you're probably right - the set of changes won't be too
significant. However, if it is possible to provide a simple
configuration option so that end-users don't have to write boilerplate
save_model() and queryset() definitions, I think that's worth looking
into.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Russell Keith-Magee]

On Sun, Dec 6, 2009 at 1:09 AM, Tobias McNulty  wrote:
> On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee
>  wrote:
>>
>> I don't grant that proposition at all. The admin interface serves as a
>> working example demonstrating that you don't need to use settings to
>> define the way models are used.
>
> Okay.  Do you grant the proposition that "we will (not necessarily in Django
> 1.2) need a project-level way to specify the default database(s) to use for
> queries to a given model," whether it is settings-based or not?

Possibly. :-)

>> At this point, I'm prognosticating because I haven't actually written
>> any code for this - but I don't think the using argument to Site()
>> would necessarily have to be deprecated. In a single-database admin,
>> the using argument tells you exactly which database is to be used; if
>> we update admin to have a fully multi-db interface in the future, the
>> value of the using argument could easily be interpreted as the
>> "default" database that is displayed.
>
> Maybe I'm just being obtuse, but there are a couple issues with the admin
> approach to which I can't see a resolution yet:
> * Assuming the above proposition is true, the behavior of the API when the
> global and admin-level configurations conflict is not at all intuitive

I'm not sure how you can make that assertion given that neither global
nor admin-level configurations for multi-db exist yet.

Might I humbly suggest that we stop speculating about the possible
limitations of a theoretical admin implementation until such time as
an implementation actually exists?

> Simon's idea seems like a reasonable (and already supported?) workaround for
> those who need to modify the admin to use a different database in specific
> cases.

Agreed. All I'm talking about is making it easier to do what Simon has
suggested, but without the need for boilerplate ModelAdmin
definitions. I'm hoping to spend the next couple of days fiddling with
this problem. Once we've got something concrete to argue about, I'll
report back.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Russell Keith-Magee]

On Sun, Dec 6, 2009 at 4:16 AM, subs...@gmail.com  wrote:
> Oh, I see from a later message by Alex that Meta.using was removed.
>
> -1!

There's a very good reason why this was removed. It isn't a model
level property. Consider - what if contrib.auth.User had a Meta
using='foo' property? If this were the case, you wouldn't be able to
reuse the contrib.auth.User model without defining a 'foo' database.
This would singlehandedly hobble the ability reuse Django
applications.

On top of that, the capability provided by Meta.using can easily be
reproduced with a custom manager. I've given an example of how this
would work in this thread.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Tests blocked by AssertionError 200 != 302 in login() calls

[Russell Keith-Magee]

On Sun, Dec 6, 2009 at 2:41 AM, Gordon A  wrote:
> Apologies if this isn't the right forum for this question.

It's unclear if you're in the right place. Django-dev is for
discussing the development of Django itself; django-users is for
general user queries. Generally, if you're unsure, django-users is the
right place to start.

> When I run "manage.py test", I get many errors of this form:
>
> FAIL: test_password_change_fails_with_invalid_old_password
>  File 
>  File tests/views.py", line 136, in login
> AssertionError 200 != 302
>
> The last line is always a call on a login() method, though the class
> varies.  So the tests aren't getting past this one issue.
>
> The error seems odd.  I would guess that response 200 would be good
> news, but don't know Django's internals enough to say.

Generally, a 200 indicates that an error has occurred in a view, and
Django is showing you the same page to display an error; a 302 means
that a form has succeeded and you have been redirected.

> I would also
> guess that the tests expect that the urls are set up so that these
> calls are redirected before getting a response, and that the urls they
> are actually meeting are handling the requests directly.  I don't know
> what I would be doing in my settings.py file, or code, that would mess
> with any of that.
>
> What is expected of my code by the test so that it can get past this
> login() call?

You haven't given specific details of exactly which tests are failing,
but I suspect you're talking about the contrib.auth tests. There are
known problems with the auth tests failing if you don't have default
templates available, but otherwise, those tests *should* be self
contained.

If password change tests are failing, it suggests that you have done
something to change the way passwords are validated, and that change
isn't compatible with Django. However, it's impossible to know what is
going wrong without more details on exactly what you have done.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[subs...@gmail.com]

Oh, I see from a later message by Alex that Meta.using was removed.

-1!

-S

On Dec 5, 3:12 pm, "subs...@gmail.com"  wrote:
> Isn't 'database' going to be an option in a model's Meta? In this
> situation, is admin going to attempt to do something different?
>
> -S
>
> On Dec 4, 9:18 am, Nan  wrote:
>
> > > 1) Ignore the problem. Admin works on the default database, but
> > > nowhere else. This is certainly less than ideal, but it would be
> > > sufficient for master/slave setups.
>
> > > 2) Use a separate admin deployment for each database. We add a 'using'
> > > argument to admin.Site(), and append .using() the queries that the
> > > admin site issues.
>
> > > 3) Modify the admin list views so that they take a ?using=db GET
> > > argument; also add a pulldown to make it easy to switch to a different
> > > database.
>
> > > (2) should be a fairly minor change; (3) would be a little more
> > > effort, but shouldn't be impossible. There is also the need for some
> > > mechanics to check whether a table is actually present on a database -
> > > just because auth is in INSTALLED_APPS doesn't mean it's been
> > > synchronized to a particular database.
>
> > > I'm open to any other suggestions - and for any offers to help out :-)
>
> > Just thinking of one more option for this -- what about specifying the
> > DB on the ModelAdmin level rather than the admin.Site level?

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[subs...@gmail.com]

Isn't 'database' going to be an option in a model's Meta? In this
situation, is admin going to attempt to do something different?

-S

On Dec 4, 9:18 am, Nan  wrote:
> > 1) Ignore the problem. Admin works on the default database, but
> > nowhere else. This is certainly less than ideal, but it would be
> > sufficient for master/slave setups.
>
> > 2) Use a separate admin deployment for each database. We add a 'using'
> > argument to admin.Site(), and append .using() the queries that the
> > admin site issues.
>
> > 3) Modify the admin list views so that they take a ?using=db GET
> > argument; also add a pulldown to make it easy to switch to a different
> > database.
>
> > (2) should be a fairly minor change; (3) would be a little more
> > effort, but shouldn't be impossible. There is also the need for some
> > mechanics to check whether a table is actually present on a database -
> > just because auth is in INSTALLED_APPS doesn't mean it's been
> > synchronized to a particular database.
>
> > I'm open to any other suggestions - and for any offers to help out :-)
>
> Just thinking of one more option for this -- what about specifying the
> DB on the ModelAdmin level rather than the admin.Site level?

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: smart if tag

[Luke Plant]

First, thanks for your review Russell, I appreciate that you've been 
doing tons of work on lots of things!

On Saturday 05 December 2009 15:39:03 Russell Keith-Magee wrote:

> Here's the review I promised. First the minor points:
> 
>  * Line 814 of templates/defaulttags.py has a wierd UTF-8 character
>  - an emdash, rather than an ASCII hyphen. I don't know what's
>  happening on your system, but this causes crashes for me
>  complaining about PEP-0263 problems.

I did add a 'coding' line to fix that, but perhaps after you pulled my 
latest code.  Anyway, it's not worth it so I removed it.

>  * The if-tag-not-02/05 tests that have been removed should be
> retained, but be testing for the TemplateSyntaxError (just like the
> if-tag-error tests do). If we're going to implement a new language
> contract and introduce some reserved words, we should test that
>  that those words are actually reserved.

There are actually other tests that check this, in the IfParser tests. 
I didn't see the usefulness of 5 different tests all checking that 
'not' is a keyword, but renumbering the following tests would be 
worse, hence the note about why they were missing. Also, it makes more 
sense to put the syntax error tests together.

>  * I'm not wild about the docs for the if tag referring how
> comparisons work "just like Python operators". We have historically
> made a big deal of templates not being Python, and while we are
> blurring the lines a little with this patch, I'd still like to
> maintain the pretense. The preceding notes about logical operators
>  is a good example of how it should be done IMHO - it gives
>  examples of how and/or work without needing to resort to saying
>  "just like Python".

Fixed now, hopefully, I've given examples for all the operators.

>  * The explanation of why {% if a > b > c %} doesn't work is a bit
> vague. At the very least, it should have an example of the correct
> implmentation - {% if a > b and b > c %}.

Fixed now.

> Now the major issues: There's only one that I found - the parsing
> strategy for complex logical expressions. "A or B and C" is parsed
>  as "(A or B) and C", not the pythonic way "A or (B and C)" (giving
>  operator precedence to AND over OR).
> 
> Personally, I found this very surprising. When I said in a previous
> email that I didn't think it was worth hobbling the if statement to
> prevent complex logical operations, I presumed it was going to be
> replaced with a full parser. Historically, it hasn't been an issue
> because we've only allowed one type of logical operator in an {% if
> %}. I think I'd rather see this tradition continued rather than
>  allow mixing in a way that will be confusing to anyone with prior
>  programming experience.

Good catch.  I think it would be nicer to fix than just disallow, 
although it could be a substantial change to the way the IfParser 
class works. I don't think it is too much work, however, because the 
hard bit is tokenizing, which has already been done.

I'm not likely to able to look at this before Tuesday.  If anyone 
wants to look at it, I think the right approach is something like the 
following: 
http://effbot.org/zone/simple-top-down-parsing.htm
(without the globals, obviously, they can be converted to instance 
variables/methods).

I don't think trying to hack this on to the current IfParser would be 
a good idea.  IfParser already has a slightly hacky way of handling 
the precedence of 'and' and 'or' relative to the other operators, and 
this is a good opportunity to replace that with something nicer.

>  Lastly, a controversial topic, but I think we need an answer on
>  this - whither {% ifequal %}? Should we be deprecating it? Given
>  the current level of usage of the ifequal/ifnotequal tags, this
>  seems excessive. Perhaps we should consider this for long-term
>  deprecation (i.e., flag it as a 2.0 deprecation)?

Yes, I see no value in deprecating this until 2.0, given how much it 
is used.

However, while I remember, there is this bug which we may need to 
revisit:

http://code.djangoproject.com/ticket/10975

Essentially, you can't use {% block %} inside an {% if %} tag, but you 
can in an {% ifequal %} tag.  Irrespective of which one is right, it 
seems unreasonable that {% if x == y %} behaves so differently from 
{% ifequal x y %} in this regard. (Actually, I didn't test that. 
Perhaps the behaviour of 'if' has changed with the smart if code).

Regards,

Luke


-- 
"Idiocy: Never underestimate the power of stupid people in large 
groups." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Session/cookie based messages (#4604)

[Tobias McNulty]

Outstanding question regarding storage/backend notwithstanding, I
uploaded a new patch here:

http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-6399c12d1773.diff

Luke, it includes a note that fail_silently only hides the error when
messages is disabled.

I'm going to give this a final whirl by converting a project or two.

Cheers,
Tobias

On Sat, Dec 5, 2009 at 2:05 PM, Tobias McNulty  wrote:
> It looks like I mis-read the original question about storage vs.
> backend, so thanks for picking this up Luke.
>
> I don't have much to add to your argument except to say that it would
> be non-trivial to move to a more strictly organized/named setup.
>
> Cheers,
> Tobias
>
> On Sat, Dec 5, 2009 at 12:51 PM, Luke Plant  wrote:
>> On Saturday 05 December 2009 13:40:40 Russell Keith-Magee wrote:
>>
>>> * I'd rather the AddMessageFailure have a more generic name (like
>>> MessageFailure). I don't see any need to be task specific in the
>>> exception class name.
>>
>> Another thing here we should think about: at the moment, fail_silently
>> only silences the error for the messages framework not being
>> installed.  But there are a lot of other ways the messages backend
>> could potentially fail.  Should we silence those errors too? I would
>> suggest not, or there should be a separate keyword argument for that.
>> But this should be clear in the docs.
>>
>>> * I don't know why I didn't pick this up earlier, but the emerging
>>> convention for pluggable backends is for the user to specify the
>>>  name of the module, and for the module to have a predictable class
>>>  name. i.e - each storage backend module should have a
>>>  "StorageEngine" class, and the user specifies the name of the
>>>  module. There is also an emerging convention to call the pluggable
>>>  bits 'backends', rather than picking a name like 'storage'. Net
>>>  result: the user should be configuring
>>>  MESSAGE_BACKEND="django.contrib.messages.backends.user_messages"
>>>  rather than
>>> MESSAGE_STORAGE =
>>> 'django.contrib.messages.storage.user_messages.LegacyFallbackStorag
>>> e'
>>
>> Hmm, it is 'emerging' only in that several established subsystems use
>> it (db, session, cache) and the e-mail stuff just added uses this
>> convention. There are other established conventions in the code base,
>> some of which are more recent IIRC:
>>
>>  * that used by the file storage classes, file upload handlers and the
>>   authentication backend where the specific class is referred to.
>>  * that used by the template loaders, where the specific callable
>>   is referred to.
>>
>> I actually much prefer the explicit naming of a class/callable. Here
>> are some arguments in favour of this method, some of which are
>> stronger than others:
>>
>>  * you can put multiple backends in one file if you want to, and you
>>   are not forced to duplicate imports or get creative with module
>>   names if you happen to have several backends that really belong
>>   in the same module.
>>
>>  * it is much more obvious for someone who does not know the code,
>>   since it doesn't rely on a convention of a class with a certain
>>   name. If they see the setting for MESSAGE_STORAGE pointing to
>>   a class, they will immediately know where the implementation is,
>>   whereas if it points to a module and the module contains multiple
>>   classes, they will have to guess which class is the main one, or
>>   browse docs/source code.
>>
>>  * it makes it less verbose and confusing if one backend refers to
>>   another (as happens with messages), because all the classes
>>   have different names, rather than having the same name.  We
>>   currently have:
>>
>>  from django.contrib.messages.storage.fallback import FallbackStorage
>>  ...
>>  class LegacyFallbackStorage(FallbackStorage):
>>    storage_classes = (UserMessagesStorage,) +
>>                       FallbackStorage.storage_classes
>>
>> which would need to be changed to:
>>
>>  from django.contrib.messages.backends import fallback
>>  ...
>>  class StorageEngine(fallback.StorageEngine):
>>    storage_classes = (UserMessageStorageEngine,) +
>>                       fallback.StorageEngine.storage_classes
>>
>> or, using 'as' for the import:
>>
>>  from django.contrib.messages.backends.fallback import StorageEngine \
>>     as FallbackStorageEngine
>>  ...
>>  class StorageEngine(FallbackStorageEngine):
>>    storage_classes = (UserMessageStorageEngine,) +
>>                       FallbackStorageEngine.storage_classes
>>
>> (the fallback storage module would have similar issues)
>>
>> The DB subsystem, which uses backends, is big and has multiple
>> classes, so it makes sense for it to be referred to by module names.
>> But if there is exactly one class which implements a feature, I don't
>> see the sense in having a setting that refers to the containing
>> module. There might be a future proofing argument here, but for
>> smaller features it sounds 

Re: Session/cookie based messages (#4604)

[Tobias McNulty]

It looks like I mis-read the original question about storage vs.
backend, so thanks for picking this up Luke.

I don't have much to add to your argument except to say that it would
be non-trivial to move to a more strictly organized/named setup.

Cheers,
Tobias

On Sat, Dec 5, 2009 at 12:51 PM, Luke Plant  wrote:
> On Saturday 05 December 2009 13:40:40 Russell Keith-Magee wrote:
>
>> * I'd rather the AddMessageFailure have a more generic name (like
>> MessageFailure). I don't see any need to be task specific in the
>> exception class name.
>
> Another thing here we should think about: at the moment, fail_silently
> only silences the error for the messages framework not being
> installed.  But there are a lot of other ways the messages backend
> could potentially fail.  Should we silence those errors too? I would
> suggest not, or there should be a separate keyword argument for that.
> But this should be clear in the docs.
>
>> * I don't know why I didn't pick this up earlier, but the emerging
>> convention for pluggable backends is for the user to specify the
>>  name of the module, and for the module to have a predictable class
>>  name. i.e - each storage backend module should have a
>>  "StorageEngine" class, and the user specifies the name of the
>>  module. There is also an emerging convention to call the pluggable
>>  bits 'backends', rather than picking a name like 'storage'. Net
>>  result: the user should be configuring
>>  MESSAGE_BACKEND="django.contrib.messages.backends.user_messages"
>>  rather than
>> MESSAGE_STORAGE =
>> 'django.contrib.messages.storage.user_messages.LegacyFallbackStorag
>> e'
>
> Hmm, it is 'emerging' only in that several established subsystems use
> it (db, session, cache) and the e-mail stuff just added uses this
> convention. There are other established conventions in the code base,
> some of which are more recent IIRC:
>
>  * that used by the file storage classes, file upload handlers and the
>   authentication backend where the specific class is referred to.
>  * that used by the template loaders, where the specific callable
>   is referred to.
>
> I actually much prefer the explicit naming of a class/callable. Here
> are some arguments in favour of this method, some of which are
> stronger than others:
>
>  * you can put multiple backends in one file if you want to, and you
>   are not forced to duplicate imports or get creative with module
>   names if you happen to have several backends that really belong
>   in the same module.
>
>  * it is much more obvious for someone who does not know the code,
>   since it doesn't rely on a convention of a class with a certain
>   name. If they see the setting for MESSAGE_STORAGE pointing to
>   a class, they will immediately know where the implementation is,
>   whereas if it points to a module and the module contains multiple
>   classes, they will have to guess which class is the main one, or
>   browse docs/source code.
>
>  * it makes it less verbose and confusing if one backend refers to
>   another (as happens with messages), because all the classes
>   have different names, rather than having the same name.  We
>   currently have:
>
>  from django.contrib.messages.storage.fallback import FallbackStorage
>  ...
>  class LegacyFallbackStorage(FallbackStorage):
>    storage_classes = (UserMessagesStorage,) +
>                       FallbackStorage.storage_classes
>
> which would need to be changed to:
>
>  from django.contrib.messages.backends import fallback
>  ...
>  class StorageEngine(fallback.StorageEngine):
>    storage_classes = (UserMessageStorageEngine,) +
>                       fallback.StorageEngine.storage_classes
>
> or, using 'as' for the import:
>
>  from django.contrib.messages.backends.fallback import StorageEngine \
>     as FallbackStorageEngine
>  ...
>  class StorageEngine(FallbackStorageEngine):
>    storage_classes = (UserMessageStorageEngine,) +
>                       FallbackStorageEngine.storage_classes
>
> (the fallback storage module would have similar issues)
>
> The DB subsystem, which uses backends, is big and has multiple
> classes, so it makes sense for it to be referred to by module names.
> But if there is exactly one class which implements a feature, I don't
> see the sense in having a setting that refers to the containing
> module. There might be a future proofing argument here, but for
> smaller features it sounds like YAGNI to me.
>
> For the cache subsystem, the name of the module (without the 'path')
> is used as the protocol part of a URI-style setting, so it also makes
> sense for it to be short and lower case.
>
> As for the e-mail and session subsystems, IMO they are using the less
> preferable convention. Some of the disadvantages mentioned above don't
> exist for the e-mail backends, because they don't use each other like
> the messages ones do.
>
> Regards,
>
> Luke
>
> --
> "Idiocy: Never underestimate the power of stupid people in large
> groups." 

Re: Session/cookie based messages (#4604)

[Tobias McNulty]

On Sat, Dec 5, 2009 at 8:40 AM, Russell Keith-Magee
 wrote:
> * Why have all the tests migrated to the Django system tests? This is
> a contrib app - the tests should be internal to the app.

They were moved to facilitate inclusion of a more complete test suite
with a test urls.py and views.py that make sure all the plumbing works
together.  In short, I wanted a way to make use of the test Client
without including the dummy code in the distribution.

I think it has also been discussed elsewhere; that some would prefer
not to deploy the tests with the production application - one more
reason to keep them in 'tests' instead of in the contrib app.

>From what I can tell, this seems to be in line with what some of the
other contrib apps are doing, such as admin and comments.

> * I'd rather the AddMessageFailure have a more generic name (like
> MessageFailure). I don't see any need to be task specific in the
> exception class name.

Sounds good - changed.

> * I don't know why I didn't pick this up earlier, but the emerging
> convention for pluggable backends is for the user to specify the name
> of the module, and for the module to have a predictable class name.
> i.e - each storage backend module should have a "StorageEngine" class,
> and the user specifies the name of the module. There is also an
> emerging convention to call the pluggable bits 'backends', rather than
> picking a name like 'storage'. Net result: the user should be
> configuring MESSAGE_BACKEND="django.contrib.messages.backends.user_messages"
> rather than
> MESSAGE_STORAGE =
> 'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'

Really?  Files definitely seem to be more on the "storage" side of things:

http://code.djangoproject.com/browser/django/trunk/django/core/files/storage.py

> * The cookie backend is still doing a conditional import for json. The
> django.utils.simplejson module already does this conditional import
> check.

Whoops, thanks.  Removed it for real this time.  :)

> The rest of my notes are minor documentation fixes:
>
> * The documentation for the message settings that modify old settings
> (MIDDLEWARE_CLASSES, TEMPLATE_CONTEXT_PROCESSORS) should have a
> ..versionchanged note to indicate that they have changed in 1.2. This
> has been done in the template API docs, but not in settings.txt.

Added.  Also added a ..versionadded in the middleware ref.

> * The deprecation note in topics/auth.txt says the new messages
> framework should be used "whenever possible". This makes it sound
> optional, when it isn't.

Updated, thanks.

> * The explanatory note in "Configuring the message engine" in the
> message docs isn't required - or at least, isn't required until
> *after* you have described the fact that storage backends are
> configurable.

Removed.

> * The markup for the note about using standard message levels in
> reusable apps should be marked up using ..note:: syntax, so it is
> rendered as a breakout box.

Fixed, thanks.

> * The explanatory note about overriding MESSAGE_LEVEL should be marked
> up as an ..admonition:: , and should probably have an example to show
> the correct technique.

Good call, added, thanks.

Other than the question about renaming storage -> backend I think we
are close to prime time.  Let me know what you think.

Cheers,
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Tests blocked by AssertionError 200 != 302 in login() calls

[Gordon A]

Apologies if this isn't the right forum for this question.

When I run "manage.py test", I get many errors of this form:

FAIL: test_password_change_fails_with_invalid_old_password
  File 
  File tests/views.py", line 136, in login
AssertionError 200 != 302

The last line is always a call on a login() method, though the class
varies.  So the tests aren't getting past this one issue.

The error seems odd.  I would guess that response 200 would be good
news, but don't know Django's internals enough to say.  I would also
guess that the tests expect that the urls are set up so that these
calls are redirected before getting a response, and that the urls they
are actually meeting are handling the requests directly.  I don't know
what I would be doing in my settings.py file, or code, that would mess
with any of that.

What is expected of my code by the test so that it can get past this
login() call?

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Session/cookie based messages (#4604)

[Luke Plant]

On Saturday 05 December 2009 13:40:40 Russell Keith-Magee wrote:

> * I'd rather the AddMessageFailure have a more generic name (like
> MessageFailure). I don't see any need to be task specific in the
> exception class name.

Another thing here we should think about: at the moment, fail_silently 
only silences the error for the messages framework not being 
installed.  But there are a lot of other ways the messages backend 
could potentially fail.  Should we silence those errors too? I would 
suggest not, or there should be a separate keyword argument for that.
But this should be clear in the docs.

> * I don't know why I didn't pick this up earlier, but the emerging
> convention for pluggable backends is for the user to specify the
>  name of the module, and for the module to have a predictable class
>  name. i.e - each storage backend module should have a
>  "StorageEngine" class, and the user specifies the name of the
>  module. There is also an emerging convention to call the pluggable
>  bits 'backends', rather than picking a name like 'storage'. Net
>  result: the user should be configuring
>  MESSAGE_BACKEND="django.contrib.messages.backends.user_messages"
>  rather than
> MESSAGE_STORAGE =
> 'django.contrib.messages.storage.user_messages.LegacyFallbackStorag
> e'

Hmm, it is 'emerging' only in that several established subsystems use 
it (db, session, cache) and the e-mail stuff just added uses this 
convention. There are other established conventions in the code base, 
some of which are more recent IIRC:

 * that used by the file storage classes, file upload handlers and the
   authentication backend where the specific class is referred to.
 * that used by the template loaders, where the specific callable
   is referred to.

I actually much prefer the explicit naming of a class/callable. Here 
are some arguments in favour of this method, some of which are 
stronger than others:

 * you can put multiple backends in one file if you want to, and you 
   are not forced to duplicate imports or get creative with module
   names if you happen to have several backends that really belong
   in the same module.

 * it is much more obvious for someone who does not know the code,
   since it doesn't rely on a convention of a class with a certain
   name. If they see the setting for MESSAGE_STORAGE pointing to 
   a class, they will immediately know where the implementation is,
   whereas if it points to a module and the module contains multiple
   classes, they will have to guess which class is the main one, or
   browse docs/source code.

 * it makes it less verbose and confusing if one backend refers to
   another (as happens with messages), because all the classes
   have different names, rather than having the same name.  We
   currently have:

 from django.contrib.messages.storage.fallback import FallbackStorage
 ...
 class LegacyFallbackStorage(FallbackStorage):
storage_classes = (UserMessagesStorage,) +
   FallbackStorage.storage_classes

which would need to be changed to:

 from django.contrib.messages.backends import fallback
 ...
 class StorageEngine(fallback.StorageEngine):
storage_classes = (UserMessageStorageEngine,) +
   fallback.StorageEngine.storage_classes

or, using 'as' for the import:

 from django.contrib.messages.backends.fallback import StorageEngine \
 as FallbackStorageEngine
 ...
 class StorageEngine(FallbackStorageEngine):
storage_classes = (UserMessageStorageEngine,) +
   FallbackStorageEngine.storage_classes

(the fallback storage module would have similar issues)

The DB subsystem, which uses backends, is big and has multiple 
classes, so it makes sense for it to be referred to by module names.  
But if there is exactly one class which implements a feature, I don't 
see the sense in having a setting that refers to the containing 
module. There might be a future proofing argument here, but for 
smaller features it sounds like YAGNI to me.

For the cache subsystem, the name of the module (without the 'path') 
is used as the protocol part of a URI-style setting, so it also makes 
sense for it to be short and lower case.

As for the e-mail and session subsystems, IMO they are using the less 
preferable convention. Some of the disadvantages mentioned above don't 
exist for the e-mail backends, because they don't use each other like 
the messages ones do.

Regards,

Luke

-- 
"Idiocy: Never underestimate the power of stupid people in large 
groups." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Ticket #11984 - mysql and errors like truncated incorrect datetime value: '0000-01-01 00:00:00'

[Sorin Sbârnea]

Hi all,

I want to bring into discussion the http://code.djangoproject.com/ticket/11984
(patch included) - I spent quite some time in order to discover what
is the real problem and to find a solution for it.

Shortly when you try to use date_hierarchy with a mysql database where
you have datetime fields with value '-00-00 00:00:00' - django
will just crash.

I know that this date is considered invalid by SQL standard but MySQL
accepts it and many old databases do still use this value instead on
NULL. In other words this may stop other people from migrating to
django.

Thanks,

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Tobias McNulty]

On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee  wrote:
>
> I don't grant that proposition at all. The admin interface serves as a
> working example demonstrating that you don't need to use settings to
> define the way models are used.
>

Okay.  Do you grant the proposition that "we will (not necessarily in Django
1.2) need a project-level way to specify the default database(s) to use for
queries to a given model," whether it is settings-based or not?

At this point, I'm prognosticating because I haven't actually written
> any code for this - but I don't think the using argument to Site()
> would necessarily have to be deprecated. In a single-database admin,
> the using argument tells you exactly which database is to be used; if
> we update admin to have a fully multi-db interface in the future, the
> value of the using argument could easily be interpreted as the
> "default" database that is displayed.


Maybe I'm just being obtuse, but there are a couple issues with the admin
approach to which I can't see a resolution yet:

* Assuming the above proposition is true, the behavior of the API when the
global and admin-level configurations conflict is not at all intuitive

* It seems like confining every admin site to a single database would lead
to needless partitioning of the admin interface for what might otherwise be
a single, cohesive site.

Simon's idea seems like a reasonable (and already supported?) workaround for
those who need to modify the admin to use a different database in specific
cases.

Cheers,
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Simon Willison]

On Dec 5, 4:20 pm, Russell Keith-Magee  wrote:
> Trust me - I don't want to do mindless busy work. However, we need to
> have some sort of answer for the admin interface - Django's admin is a
> big selling point for Django for some people, so we can't really
> introduce a huge new feature, and then say "but you can't use it in
> admin". I'm interested in making the least intrusive change that is
> possible without hamstringing future multi-db interfaces.

It strikes me that the admin issue should be solvable entirely in
django.contrib.admin without any changes to the multidb code itself.
Right now you can get most of the job done using a ModelAdmin
subclass:

from django.contrib import admin
from blog.models import Entry

class EntryAdmin(admin.ModelAdmin):
def save_model(self, request, obj, form, change):
obj.save(using='otherdb')

def queryset(self, request):
return Entry.objects.using('otherdb').all()

admin.site.register(Entry, EntryAdmin)

I haven't tested the above so it's probably missing a few cases
(save_fieldsets for example perhaps) but if we document it I think
it's a good enough solution for the moment. Even if we need to
refactor ModelAdmin a bit to ensure the right hooks are available it
still shouldn't be a massive change.

Cheers,

Simon

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Russell Keith-Magee]

On Sat, Dec 5, 2009 at 11:33 PM, Waldemar Kornewald
 wrote:
> Hi Russell,
>
> On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee
>  wrote:
>> On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald  
>> wrote:
>>> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
>>>  wrote:
 The idea of using a function that returns a single string but does
 other processing is a novel approach, and one that I hadn't
 considered. However, I'm not sure I'm especially fond of the idea of
 requiring imports in a settings file, and the syntax you propose is
 quite verbose. I'll have to think about this a bit. Thanks for the
 suggestion, though.
>>>
>>> Shouldn't all this be more abstract? For our non-relational branch we
>>> thought about something more flexible like a list of query proxies
>>> that sit between QuerySet/Model and sql.Query (QueryData in nonrel)
>>> and that can intercept query execution and instead run their own query
>>> code.
>>
>> I'm afraid I don't see the connection between what you're describing,
>> and the problem we actually have.
>>
>> The problem is determining whether model X is available on database Y.
>> This is only required for metaprogramming purposes - so, for example,
>> syncdb knows which models to synchronize onto a particular database,
>> or an admin interface knows which models can be shown to the end user.
>>
>> As best as I can make out, you're addressing the problem that I've
>> said we aren't addressing - that of presenting a useful end-user API
>> for tasks like master/slave. If I'm mistaken, feel free to correct me
>> - preferably with some sample code to demonstrate what you're talking
>> about.
>
> Yes and no. Aren't both tasks (model location and
> sharding/slave API) highly connected?

Well, yes, they are connected - there is a one way dependency. We can
have a solution for model locations that doesn't require a solution
for public API, but not the other way around.

> We don't know what the API for sharding, master/slave, etc. will look
> like, but I have the impression that we're already defining its
> settings format and planning changes that won't be necessary with
> Django 1.3, anymore.

Others in this thread might be convinced of the need for a setting,
but I really *don't* want to introduce a setting at this point in
proceedings.

I asked for feedback, and concern about the absence of a setting
providing database-model assignments is useful feedback. I've
explained why there isn't such a setting in the code at the moment. If
someone is able to come up with an elegant solution to the problem,
I'm interested in hearing it. If I'm discussing settings formats, it's
only in the context of exploring options that we may not have
previously considered.

As I've mentioned a few times now, I'm acutely aware of the fact that
this patch doesn't address public API issues for common use cases, and
I don't want to introduce features in this release that we need to
deprecate in later releases.

> For example, as my suggestion shows, the admin
> interface does not have to (and must not!) know about the multi-db
> setup because that can be fully abstracted behind an sql.Query proxy
> API (actually, it must be abstracted that way because there can be
> lots of different ways to do sharding and you don't want high-level
> code to deal with those details).

Trust me - I don't want to do mindless busy work. However, we need to
have some sort of answer for the admin interface - Django's admin is a
big selling point for Django for some people, so we can't really
introduce a huge new feature, and then say "but you can't use it in
admin". I'm interested in making the least intrusive change that is
possible without hamstringing future multi-db interfaces.

> I am just concerned that you'll waste time on implementing something
> that will get removed in 1.3 shortly thereafter just because multi-db
> isn't ready for real-world use-cases, yet. I'd rather have a temporary
> very simple hack that binds a model to a single DB and that doesn't
> require any changes to the admin interface itself and code that uses
> the admin UI. This could indeed be specified in the settings as was
> already suggested. But it should be clear that this is just a
> temporary hack and 1.3 will provide a clean solution.

In a previous message in this thread, I described a temporary hack to
bind a model to a specific database - override get_query_set() on the
model manager. It's not a perfect solution for all situations, but it
is a workable hack, and it doesn't require any settings, temporary or
otherwise.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more 

Re: Multiple database support: Request for feedback and testing

[Russell Keith-Magee]

On Sat, Dec 5, 2009 at 11:15 PM, Tobias McNulty  wrote:
> On Sat, Dec 5, 2009 at 8:58 AM, Russell Keith-Magee
>  wrote:
>> As best as I can make out, you're addressing the problem that I've
>> said we aren't addressing - that of presenting a useful end-user API
>> for tasks like master/slave. If I'm mistaken, feel free to correct me
>> - preferably with some sample code to demonstrate what you're talking
>> about.
>
> Yes - it sounds to me like Waldemar might be talking about the
> "registration/callback API to allow you control database assignment on
> a per-query basis" that you mention above.  I hadn't thought about
> this before, but I like the idea and I think it'll be crucial in
> implementing some of the more complex partitioning cases.
>
> It seems like it'll be necessary in addition to some sort of
> settings-based map of what apps/models go in what databases.

I don't grant that proposition at all. The admin interface serves as a
working example demonstrating that you don't need to use settings to
define the way models are used.

I'm not saying that this is necessarily the best way to solve the
problem - just that a setting-based map isn't an absolute given. There
are many viable alternatives, all of which we can explore when we
actually have working multi-db plumbing in the field.

> Quick question: will the admin.Site method be useful in addition to
> whatever more global method we come up with for designating what
> tables go in what databases, or will it be obsolete (and potentially
> deprecated) at that point?  I can't see a reason that one would want
> to modify the database(s) the admin uses irrespective of the global
> settings.

At this point, I'm prognosticating because I haven't actually written
any code for this - but I don't think the using argument to Site()
would necessarily have to be deprecated. In a single-database admin,
the using argument tells you exactly which database is to be used; if
we update admin to have a fully multi-db interface in the future, the
value of the using argument could easily be interpreted as the
"default" database that is displayed.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: smart if tag

[Russell Keith-Magee]

On Tue, Dec 1, 2009 at 9:55 AM, Russell Keith-Magee
 wrote:
> On Tue, Dec 1, 2009 at 1:08 AM, Luke Plant  wrote:
>> Patch
>> =
>>
>> Review would be welcome, especially as I'm ill at the moment. I'm only
>> coding because the boredom of doing nothing is killing me...
>
> I'll try and take a look over the next couple of days.

Here's the review I promised. First the minor points:

 * Line 814 of templates/defaulttags.py has a wierd UTF-8 character -
an emdash, rather than an ASCII hyphen. I don't know what's happening
on your system, but this causes crashes for me complaining about
PEP-0263 problems.

 * The if-tag-not-02/05 tests that have been removed should be
retained, but be testing for the TemplateSyntaxError (just like the
if-tag-error tests do). If we're going to implement a new language
contract and introduce some reserved words, we should test that that
those words are actually reserved.

 * I'm not wild about the docs for the if tag referring how
comparisons work "just like Python operators". We have historically
made a big deal of templates not being Python, and while we are
blurring the lines a little with this patch, I'd still like to
maintain the pretense. The preceding notes about logical operators is
a good example of how it should be done IMHO - it gives examples of
how and/or work without needing to resort to saying "just like
Python".

 * The explanation of why {% if a > b > c %} doesn't work is a bit
vague. At the very least, it should have an example of the correct
implmentation - {% if a > b and b > c %}.

 * The interaction between this patch and #6262 will be fun. (This is
more a mental note to myself that I should commit #6262)

Now the major issues: There's only one that I found - the parsing
strategy for complex logical expressions. "A or B and C" is parsed as
"(A or B) and C", not the pythonic way "A or (B and C)" (giving
operator precedence to AND over OR).

Personally, I found this very surprising. When I said in a previous
email that I didn't think it was worth hobbling the if statement to
prevent complex logical operations, I presumed it was going to be
replaced with a full parser. Historically, it hasn't been an issue
because we've only allowed one type of logical operator in an {% if
%}. I think I'd rather see this tradition continued rather than allow
mixing in a way that will be confusing to anyone with prior
programming experience.

Lastly, a controversial topic, but I think we need an answer on this -
whither {% ifequal %}? Should we be deprecating it? Given the current
level of usage of the ifequal/ifnotequal tags, this seems excessive.
Perhaps we should consider this for long-term deprecation (i.e., flag
it as a 2.0 deprecation)?

Russ %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Waldemar Kornewald]

Hi Russell,

On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee
 wrote:
> On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald  
> wrote:
>> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
>>  wrote:
>>> The idea of using a function that returns a single string but does
>>> other processing is a novel approach, and one that I hadn't
>>> considered. However, I'm not sure I'm especially fond of the idea of
>>> requiring imports in a settings file, and the syntax you propose is
>>> quite verbose. I'll have to think about this a bit. Thanks for the
>>> suggestion, though.
>>
>> Shouldn't all this be more abstract? For our non-relational branch we
>> thought about something more flexible like a list of query proxies
>> that sit between QuerySet/Model and sql.Query (QueryData in nonrel)
>> and that can intercept query execution and instead run their own query
>> code.
>
> I'm afraid I don't see the connection between what you're describing,
> and the problem we actually have.
>
> The problem is determining whether model X is available on database Y.
> This is only required for metaprogramming purposes - so, for example,
> syncdb knows which models to synchronize onto a particular database,
> or an admin interface knows which models can be shown to the end user.
>
> As best as I can make out, you're addressing the problem that I've
> said we aren't addressing - that of presenting a useful end-user API
> for tasks like master/slave. If I'm mistaken, feel free to correct me
> - preferably with some sample code to demonstrate what you're talking
> about.

Yes and no. Aren't both tasks (model location and
sharding/slave API) highly connected?

We don't know what the API for sharding, master/slave, etc. will look
like, but I have the impression that we're already defining its
settings format and planning changes that won't be necessary with
Django 1.3, anymore. For example, as my suggestion shows, the admin
interface does not have to (and must not!) know about the multi-db
setup because that can be fully abstracted behind an sql.Query proxy
API (actually, it must be abstracted that way because there can be
lots of different ways to do sharding and you don't want high-level
code to deal with those details).

I am just concerned that you'll waste time on implementing something
that will get removed in 1.3 shortly thereafter just because multi-db
isn't ready for real-world use-cases, yet. I'd rather have a temporary
very simple hack that binds a model to a single DB and that doesn't
require any changes to the admin interface itself and code that uses
the admin UI. This could indeed be specified in the settings as was
already suggested. But it should be clear that this is just a
temporary hack and 1.3 will provide a clean solution.

Bye,
Waldemar Kornewald

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Tobias McNulty]

On Sat, Dec 5, 2009 at 8:58 AM, Russell Keith-Magee
 wrote:
> As best as I can make out, you're addressing the problem that I've
> said we aren't addressing - that of presenting a useful end-user API
> for tasks like master/slave. If I'm mistaken, feel free to correct me
> - preferably with some sample code to demonstrate what you're talking
> about.

Yes - it sounds to me like Waldemar might be talking about the
"registration/callback API to allow you control database assignment on
a per-query basis" that you mention above.  I hadn't thought about
this before, but I like the idea and I think it'll be crucial in
implementing some of the more complex partitioning cases.

It seems like it'll be necessary in addition to some sort of
settings-based map of what apps/models go in what databases.

Quick question: will the admin.Site method be useful in addition to
whatever more global method we come up with for designating what
tables go in what databases, or will it be obsolete (and potentially
deprecated) at that point?  I can't see a reason that one would want
to modify the database(s) the admin uses irrespective of the global
settings.

Cheers,
Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Signals for ManyToMany relations question

[Russell Keith-Magee]

On Sat, Dec 5, 2009 at 10:56 AM, Russell Keith-Magee
 wrote:
> On Sat, Dec 5, 2009 at 5:35 AM, Ryan K  wrote:
>>
>> I hope I'm not missing something glaringly obvious but the idea would
>> be that an option in the Django instance's settings would enable this
>> feature (or maybe as a decorator for each model or explicitly giving
>> the model a special manager).
>
> Stepping aside from the fact that class decorators are only available
> in Django 3.0...

Of course, that should read _Python_ 3.0.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Russell Keith-Magee]

On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald  wrote:
> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
>  wrote:
>> The idea of using a function that returns a single string but does
>> other processing is a novel approach, and one that I hadn't
>> considered. However, I'm not sure I'm especially fond of the idea of
>> requiring imports in a settings file, and the syntax you propose is
>> quite verbose. I'll have to think about this a bit. Thanks for the
>> suggestion, though.
>
> Shouldn't all this be more abstract? For our non-relational branch we
> thought about something more flexible like a list of query proxies
> that sit between QuerySet/Model and sql.Query (QueryData in nonrel)
> and that can intercept query execution and instead run their own query
> code.

I'm afraid I don't see the connection between what you're describing,
and the problem we actually have.

The problem is determining whether model X is available on database Y.
This is only required for metaprogramming purposes - so, for example,
syncdb knows which models to synchronize onto a particular database,
or an admin interface knows which models can be shown to the end user.

As best as I can make out, you're addressing the problem that I've
said we aren't addressing - that of presenting a useful end-user API
for tasks like master/slave. If I'm mistaken, feel free to correct me
- preferably with some sample code to demonstrate what you're talking
about.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Session/cookie based messages (#4604)

[Russell Keith-Magee]

On Mon, Nov 30, 2009 at 8:28 PM, Russell Keith-Magee
 wrote:
> I'll take another look at this patch next week to make sure I haven't
> missed anything. Assuming I don't find anything new and interesting
> (and assuming you're happy with my response on the API issues), this
> should be able to land in trunk in the very near future.

Ok - final pass review notes. I have four substantive comments:

* Why have all the tests migrated to the Django system tests? This is
a contrib app - the tests should be internal to the app.

* I'd rather the AddMessageFailure have a more generic name (like
MessageFailure). I don't see any need to be task specific in the
exception class name.

* I don't know why I didn't pick this up earlier, but the emerging
convention for pluggable backends is for the user to specify the name
of the module, and for the module to have a predictable class name.
i.e - each storage backend module should have a "StorageEngine" class,
and the user specifies the name of the module. There is also an
emerging convention to call the pluggable bits 'backends', rather than
picking a name like 'storage'. Net result: the user should be
configuring MESSAGE_BACKEND="django.contrib.messages.backends.user_messages"
rather than
MESSAGE_STORAGE =
'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'

* The cookie backend is still doing a conditional import for json. The
django.utils.simplejson module already does this conditional import
check.

The rest of my notes are minor documentation fixes:

* The documentation for the message settings that modify old settings
(MIDDLEWARE_CLASSES, TEMPLATE_CONTEXT_PROCESSORS) should have a
..versionchanged note to indicate that they have changed in 1.2. This
has been done in the template API docs, but not in settings.txt.

* The deprecation note in topics/auth.txt says the new messages
framework should be used "whenever possible". This makes it sound
optional, when it isn't.

* The explanatory note in "Configuring the message engine" in the
message docs isn't required - or at least, isn't required until
*after* you have described the fact that storage backends are
configurable.

* The markup for the note about using standard message levels in
reusable apps should be marked up using ..note:: syntax, so it is
rendered as a breakout box.

* The explanatory note about overriding MESSAGE_LEVEL should be marked
up as an ..admonition:: , and should probably have an example to show
the correct technique.

Russ %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Waldemar Kornewald]

On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
 wrote:
> The idea of using a function that returns a single string but does
> other processing is a novel approach, and one that I hadn't
> considered. However, I'm not sure I'm especially fond of the idea of
> requiring imports in a settings file, and the syntax you propose is
> quite verbose. I'll have to think about this a bit. Thanks for the
> suggestion, though.

Shouldn't all this be more abstract? For our non-relational branch we
thought about something more flexible like a list of query proxies
that sit between QuerySet/Model and sql.Query (QueryData in nonrel)
and that can intercept query execution and instead run their own query
code.

For example, a proxy could emulate unsupported DB features like
select_related for non-relational DBs. You could also use this for
selecting the connection for each query (e.g., sharding by pk) and for
spreading a single query across multiple DBs at the same time (e.g.,
if you want to find all users born in 1980 you'll have to run this
query on all DBs of a sharded users table).

The point is, QuerySet and Model shouldn't care about those details.
They should only provide a high-level abstraction to the DB that is as
expressive and simple as possible. The details can be implemented via
add-ons, so everyone can map the DB abstraction to his real DB setup.

Bye,
Waldemar Kornewald

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Russell Keith-Magee]

On Sat, Dec 5, 2009 at 4:07 PM, Johannes Dollinger
 wrote:
>
> Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee:
>> [...]
>>> What if the admin was instead fixed
>>> by providing facilities for the more general case outlined above?
>>>
>>> What would this look like?  I'm picturing another setting (bleh) that
>>> maps apps and/or models to specific databases.  Name choices aside,
>>> this might look something like:
>>>
>>> DATABASE_USING = {
>>>     'django.contrib.auth': 'default',
>>>     'myapp': 'database1',
>>>     'myapp2': {
>>>         'Model1': 'database2',
>>>         'Model2': 'database3',
>>>     }
>>> }
>>>
>>> The admin could automatically take advantage of this setting to
>>> determine what database to use for a given model.
>>
>> Alex, Joseph Kocherhans and I discussed this exact idea at Djangocon.
>> You are correct that it has a lot of potential uses - not only the
>> admin, but also loaddata/dumpdata, syncdb, and anywhere else that an
>> iteration over models is required.
>>
>> However, it's a little bit more complicated than you make out.
>>
>> This sort of setting is very easy to give as a 10 line example, but in
>> practice, this isn't what you will require - you will effectively need
>> to duplicate the contents of INSTALLED_APPS. I have projects in the
>> wild with dozens of entries in INSTALLED_APS - all running on a single
>> database. Writing a DATABASE_USING setting like the one you describe
>> would be extremely cumbersome and annoying.
>>
>> So, we could hijack INSTALLED_APPS to represent the idea of database
>> deployment, using tuples/dictionaries rather than strings to define
>> how apps are deployed. However, this comes at the cost of backwards
>> compatibility for anyone iterating over INSTALLED_APPS.
>> [...]
>
> Let me propose a different colored pattern. It's backwards compatible,
> dry, feels like the urlconf approach and may evolve into a fix for
> #3591:
>
> INSTALLED_APPS = (
>        app('django.contrib.auth', using=...),
>        app('myapp'),
>        app('myapp2', models=(
>                model('Model1', using=...),
>                model('Model2', using=...),
>        ),
> )
>
> Where `app()` would look like this:
>
> APP_USING = {}
>
> def app(path, **kwargs):
>        if 'using' in kwargs:
>                APP_USING[path] = kwargs['using']
>        ...
>        return path
>
> The downside: It would require an import in settings.py. And the
> global dict is not exactly beautiful - but the price for bc.

The idea of using a function that returns a single string but does
other processing is a novel approach, and one that I hadn't
considered. However, I'm not sure I'm especially fond of the idea of
requiring imports in a settings file, and the syntax you propose is
quite verbose. I'll have to think about this a bit. Thanks for the
suggestion, though.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Multiple database support: Request for feedback and testing

[Johannes Dollinger]

Am 05.12.2009 um 06:36 schrieb Russell Keith-Magee:
> [...]
>> What if the admin was instead fixed
>> by providing facilities for the more general case outlined above?
>>
>> What would this look like?  I'm picturing another setting (bleh) that
>> maps apps and/or models to specific databases.  Name choices aside,
>> this might look something like:
>>
>> DATABASE_USING = {
>> 'django.contrib.auth': 'default',
>> 'myapp': 'database1',
>> 'myapp2': {
>> 'Model1': 'database2',
>> 'Model2': 'database3',
>> }
>> }
>>
>> The admin could automatically take advantage of this setting to
>> determine what database to use for a given model.
>
> Alex, Joseph Kocherhans and I discussed this exact idea at Djangocon.
> You are correct that it has a lot of potential uses - not only the
> admin, but also loaddata/dumpdata, syncdb, and anywhere else that an
> iteration over models is required.
>
> However, it's a little bit more complicated than you make out.
>
> This sort of setting is very easy to give as a 10 line example, but in
> practice, this isn't what you will require - you will effectively need
> to duplicate the contents of INSTALLED_APPS. I have projects in the
> wild with dozens of entries in INSTALLED_APS - all running on a single
> database. Writing a DATABASE_USING setting like the one you describe
> would be extremely cumbersome and annoying.
>
> So, we could hijack INSTALLED_APPS to represent the idea of database
> deployment, using tuples/dictionaries rather than strings to define
> how apps are deployed. However, this comes at the cost of backwards
> compatibility for anyone iterating over INSTALLED_APPS.
> [...]

Let me propose a different colored pattern. It's backwards compatible,  
dry, feels like the urlconf approach and may evolve into a fix for  
#3591:

INSTALLED_APPS = (
app('django.contrib.auth', using=...),
app('myapp'),
app('myapp2', models=(
model('Model1', using=...),
model('Model2', using=...),
),
)

Where `app()` would look like this:

APP_USING = {}

def app(path, **kwargs):
if 'using' in kwargs:
APP_USING[path] = kwargs['using']
...
return path

The downside: It would require an import in settings.py. And the  
global dict is not exactly beautiful - but the price for bc.

This is not really an argument for a settings based solution (+0). But  
if there will be one, don't make it nested tuples/dicts - the  
existance of tuple literals in python does not make s-expressions a  
natural representation of configuration.
__
Johannes

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.