Re: Bug with testing framework when not using contrib.auth

[Russell Keith-Magee]

On Thu, Nov 4, 2010 at 3:58 AM, Yo-Yo Ma  wrote:
> Ok, thanks. I'm using CookieStorage for messages, so the issue may not
> reside only with legacy storage. Should I create a ticket for this?

If you'd be so kind.

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: Bug with testing framework when not using contrib.auth

[Yo-Yo Ma]

Ok, thanks. I'm using CookieStorage for messages, so the issue may not
reside only with legacy storage. Should I create a ticket for this?


On Nov 3, 6:11 am, Russell Keith-Magee 
wrote:
> On Wed, Nov 3, 2010 at 1:43 PM, Yo-Yo Ma  wrote:
> > I've been using CookieStorage (for less DB usage). Us that frowned
> > upon nowadays, in favor of the DB backend?
>
> There is no "db" backend for messages, there is only a "legacy"
> backend, which, as the name suggests, is for legacy applications --
> applications that used Django's older (pre 1.2) user-messages table
> and need to migrate to using the Django-1.2 messages framework.
>
> There is a db backend for sessions, but the choice of session backend
> is independent of the choice of messages backend.
>
> The "right" solution is entirely up to your own requirements; Django
> doesn't discourage the use of any of the options it provides, other
> than to say that the legacy backend only exists for backwards
> compatibility purposes.
>
> 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: Bump/question for #13956

[Sean Brant]

Has supporting kwargs along with args been mentioned? I would find
having both very helpful. Maybe we can lean on the work happening for
the include and with tags.


On Wed, Nov 3, 2010 at 10:06 AM, Stephen Burrows
 wrote:
> As far as I know, the only thing still missing from the ticket is a
> decision as to whether there need to be documentation changes for
> simple tags and inclusion tags... if there need to be changes, I could
> try working on them. I would just need to know.
> Best,
> Stephen
>
> --
> 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.
>
>

-- 
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: Bump/question for #13956

[Stephen Burrows]

As far as I know, the only thing still missing from the ticket is a
decision as to whether there need to be documentation changes for
simple tags and inclusion tags... if there need to be changes, I could
try working on them. I would just need to know.
Best,
Stephen

-- 
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: Git-using core devs: preference for merge vs. rebase?

[Carl Meyer]

Hi Tom,

On Nov 2, 12:58 pm, "Tom X. Tobin"  wrote:
> Do the Git-using core developers have a preference for merge vs.
> rebase for updating an upstream-tracking branch?  I prefer to rebase
> to keep the changes in question at the branch HEAD, especially if the
> branch hasn't been pushed publicly yet, but a rebase for something
> that *has* been pushed means a forced overwrite is necessary, which
> may trip up anyone who has already added the branch as a remote and
> isn't expecting it.

I understand the appeal of keeping the changes nice and linear at the
head, but in practice I find merging pretty easy to deal with. With
github compare view (and command-line equivalents "git diff
master...branchname" and "git log master...branchname") it's still
quite easy to tease out the actual changes in the branch for review.
Merging also keeps commit messages accurate for long-running feature
branches, and avoids the forcing hassles for anyone trying to track
your branch.

For something you haven't pushed in public yet, of course rebasing is
fine.

Carl

-- 
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: Ticket #7817: Extending "with" and "include" tags.

[Łukasz Rekucki]

On 3 November 2010 10:03, Jannis Leidel  wrote:
> On 27.10.2010, at 09:46, SmileyChris wrote:
>
>> On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
>>> I would like to bring this up again, because this is something that
>>> would really improve readability of my templates. I'm mainly
>>> interested in ticket #7817 (the include tag changes), but extending
>>> "with" tag (ticket 9456) would keep things consistent.
>>
>> Here's a link to the ticket for the lazier ones among us:
>> http://code.djangoproject.com/ticket/7817
>>
>> The main decision which needs to be made is one of syntax.
>>
>> The current proposal uses:
>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>> but this introduces an inconsistency with the {% with %} tag.
>
> I'm feeling strongly against moving from the "value as name" to the 
> "name=value" notation, since I think the former is actually more readable 
> than the latter for the targetted audience (template authors).
>
>> Consistency would be nice, but I think this starts to look a bit
>> confusing, static tokens outnumbering actual functional ones:
>> {% include "name_snippet.html" with name as "Joe" and greeting as
>> "Hello" %}
>
> Well, I think that's actually not a bad notation at all (if using the correct 
> order :), so for #7817 I propose the following syntax (as analogously 
> proposed by #9456 for {% with %}):
>
> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}

My argument against this is that it's not consistent use of "as". Take
the {% url %} tag:

{% url my_view object_id=5 section="B" as my_view_url %}

There is clear separation about what is an argument to the tag and
what is being set in current scope. Now {% with %} and {% blocktrans
%} behave the same with a small difference of changing current scope.

{% with "John" as person_name %}
{# context was changed by using "as" and person_name is now availble #}
{% endwith %}

Thus I would leave {% with %} and {% blocktrans %} with this syntax as
it's intuitive and readable. The proposed change to {% include %} is a
bit diffrent. Currently, there is a way to write inclusion tags and
pass arguments to them, that usually land in the context. So my custom
inclusion tag right now will look like this:

{% show_note note "Title" %}

If we were to extend the inclusion tag shortcut to support keyword
arguments I think most people would expect it to look like this:

{% show_note note=object title="Title" %}

rather than:

{% show_note object as note and "Title" as title %}

because that's how most tags get their arguments passed. {% include %}
with proposed extensions can be considered as a inclusion_tag with a
variable template name:

{% include "foo.html" x=1 y=2 %}

It takes arguments and doesn't modify scope, so It should be
consistent with tags that do the same. The interleaving "with" keyword
could be removed not to confuse people.

-- 
Łukasz Rekucki

-- 
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: Ticket #7817: Extending "with" and "include" tags.

[burc...@gmail.com]

On Wed, Nov 3, 2010 at 5:18 PM, Jannis Leidel  wrote:
> On 03.11.2010, at 12:01, burc...@gmail.com wrote:
>
>> Hi Jannis,
>>
>> On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel  wrote:
>>> On 27.10.2010, at 09:46, SmileyChris wrote:
>>>
 On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
> I would like to bring this up again, because this is something that
> would really improve readability of my templates. I'm mainly
> interested in ticket #7817 (the include tag changes), but extending
> "with" tag (ticket 9456) would keep things consistent.

 Here's a link to the ticket for the lazier ones among us:
 http://code.djangoproject.com/ticket/7817

 The main decision which needs to be made is one of syntax.

 The current proposal uses:
 {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
 but this introduces an inconsistency with the {% with %} tag.
>>>
>>> I'm feeling strongly against moving from the "value as name" to the 
>>> "name=value" notation, since I think the former is actually more readable 
>>> than the latter for the targetted audience (template authors).
>>
>> If you are not asking real people, it's a speculation anyway.
>
> Heh, so you are saying my gut feeling is speculative, I'm not sure what to 
> respond to that. In any case, you are implying that I'm not "real people" -- 
> what ever that is -- I can assure you that I use templates as a programmer 
> and a designer. In case you think "we programmers can do whatever we want, 
> the designer won't even notice the api change", I have to admit the designer 
> in me feels a little insulted.
>
> It does make a difference to use a mathamatical sign in a commonly used 
> aspect of the template language than prose.  Note, I'm not saying that I 
> disagree with getting rid of warts (#7817, #9456), but actually proposed a 
> compromise that was already mentioned by another core dev.
I also don't disagree, just not completely agree with your reasoning.

Sorry for being harsh. Just "my inner designer" gets confused when
someone calls "as" and "and" much useful for purpose of setting
variables rather than "=". Hm Maybe because HTML uses "=" for
setting attributes? :)

 Consistency would be nice, but I think this starts to look a bit
 confusing, static tokens outnumbering actual functional ones:
 {% include "name_snippet.html" with name as "Joe" and greeting as
 "Hello" %}
>>>
>>> Well, I think that's actually not a bad notation at all (if using the 
>>> correct order :), so for #7817 I propose the following syntax (as 
>>> analogously proposed by #9456 for {% with %}):
>>>
>>> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>
> --
> 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.
>
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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: Potential mistake in docs.

[Russell Keith-Magee]

On Wed, Nov 3, 2010 at 3:06 PM, Yo-Yo Ma  wrote:
> In the related_name docs (
> http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name
> ) you read about how you must specify a related_name for any foreign
> key in an abstract base class. This doesn't seem to be true in
> practice (I'm using trunk from a week ago, or so). The models I have
> that subclass my ABM work just fine, and no warnings are raised during
> validation. This might simply be a change that went documented.

It's not quite as simple as that; you *should* specify a related_name
for any foreign key on an abstract base class, but it will only become
a problem when you have two concrete subclasses of the abstract base.
If you think about what will happen with backreferences on the
concrete subclasses, it should be fairly obvious why this is a
problem.

If you will only ever have one concrete subclass, you won't see this
problem, but as a defensive measure for the general case, the advice
given by the documentation is sound.

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: Bug with testing framework when not using contrib.auth

[Russell Keith-Magee]

On Wed, Nov 3, 2010 at 1:43 PM, Yo-Yo Ma  wrote:
> I've been using CookieStorage (for less DB usage). Us that frowned
> upon nowadays, in favor of the DB backend?

There is no "db" backend for messages, there is only a "legacy"
backend, which, as the name suggests, is for legacy applications --
applications that used Django's older (pre 1.2) user-messages table
and need to migrate to using the Django-1.2 messages framework.

There is a db backend for sessions, but the choice of session backend
is independent of the choice of messages backend.

The "right" solution is entirely up to your own requirements; Django
doesn't discourage the use of any of the options it provides, other
than to say that the legacy backend only exists for backwards
compatibility purposes.

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: Ticket #7817: Extending "with" and "include" tags.

[Jannis Leidel]

On 03.11.2010, at 12:01, burc...@gmail.com wrote:

> Hi Jannis,
> 
> On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel  wrote:
>> On 27.10.2010, at 09:46, SmileyChris wrote:
>> 
>>> On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
 I would like to bring this up again, because this is something that
 would really improve readability of my templates. I'm mainly
 interested in ticket #7817 (the include tag changes), but extending
 "with" tag (ticket 9456) would keep things consistent.
>>> 
>>> Here's a link to the ticket for the lazier ones among us:
>>> http://code.djangoproject.com/ticket/7817
>>> 
>>> The main decision which needs to be made is one of syntax.
>>> 
>>> The current proposal uses:
>>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>>> but this introduces an inconsistency with the {% with %} tag.
>> 
>> I'm feeling strongly against moving from the "value as name" to the 
>> "name=value" notation, since I think the former is actually more readable 
>> than the latter for the targetted audience (template authors).
> 
> If you are not asking real people, it's a speculation anyway.

Heh, so you are saying my gut feeling is speculative, I'm not sure what to 
respond to that. In any case, you are implying that I'm not "real people" -- 
what ever that is -- I can assure you that I use templates as a programmer and 
a designer. In case you think "we programmers can do whatever we want, the 
designer won't even notice the api change", I have to admit the designer in me 
feels a little insulted.

It does make a difference to use a mathamatical sign in a commonly used aspect 
of the template language than prose.  Note, I'm not saying that I disagree with 
getting rid of warts (#7817, #9456), but actually proposed a compromise that 
was already mentioned by another core dev.

>>> Consistency would be nice, but I think this starts to look a bit
>>> confusing, static tokens outnumbering actual functional ones:
>>> {% include "name_snippet.html" with name as "Joe" and greeting as
>>> "Hello" %}
>> 
>> Well, I think that's actually not a bad notation at all (if using the 
>> correct order :), so for #7817 I propose the following syntax (as 
>> analogously proposed by #9456 for {% with %}):
>> 
>> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}

-- 
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.

Potential mistake in docs.

[Yo-Yo Ma]

In the related_name docs (
http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name
) you read about how you must specify a related_name for any foreign
key in an abstract base class. This doesn't seem to be true in
practice (I'm using trunk from a week ago, or so). The models I have
that subclass my ABM work just fine, and no warnings are raised during
validation. This might simply be a change that went documented.

-- 
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: Bug with testing framework when not using contrib.auth

[Yo-Yo Ma]

BTW, my program doesn't have any issues with gangrene. I meant "a slew
of 35 errors" in my original post. Sometimes I look back at what I've
typed and it amazes me.

On Nov 2, 6:26 pm, Russell Keith-Magee 
wrote:
> On Wed, Nov 3, 2010 at 8:18 AM, David P. Novakovic
>
>  wrote:
> > This is certainly an artifact of the fact that messages recent started
> > supporting anonymous messages. Previously it depended on auth.
>
> > I suspect you just need to open a ticket for this.
>
> Yes - this is oversight, not intention.
>
> contrib.messages depends on contrib.auth for reasons of backwards
> compatibility, but unless you're using the legacy fallback storage
> mechanism, that dependency doesn't exist in practice. You're the first
> person to report this dependency as a practical concern.
>
> I suspect we'll need to crack out some of the new unittest2 features
> to fix this; skipping the user_messages tests unless contrib.auth is
> available.
>
> Yours,
> Russ Magee %-)
>
>
>
> > On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma  wrote:
> >> I have a large application that doesn't user contrib.auth, and when I
> >> run `manage.py test` I get a slough of 35 errors, all of which are
> >> DatabaseError: no such table: auth_user (differing Tracebacks for
> >> each). I don't have any actual tests yet, just the SimpleTest that
> >> comes free in tests.py. INSTALLED_APPS is:
>
> >>    'django.contrib.sessions',
> >>    'django.contrib.messages',
> >>    'myproject.myapp',  # Plus 8 more custom apps omitted.
>
> >> With this bug, Django's testing framework is seemingly coupled to a
> >> contrib app.
>
> >> One of the Tracebacks:
>
> >> ==
> >> ERROR: test_add
> >> (django.contrib.messages.tests.user_messages.UserMessagesTest)
> >> --
> >> Traceback (most recent call last):
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\contrib
> >> \messages\tests\user_messages.py", line 13, in setUp
> >>    self.user = User.objects.create(username='tester')
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \manager.py", line 138, in create
> >>    return self.get_query_set().create(**kwargs)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \query.py", line 351, in create
> >>    obj.save(force_insert=True, using=self.db)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \base.py", line 452, in save
> >>    self.save_base(using=using, force_insert=force_insert,
> >> force_update=force_update)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \base.py", line 545, in save_base
> >>    result = manager._insert(values, return_id=update_pk, using=using)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \manager.py", line 195, in _insert
> >>    return insert_query(self.model, values, **kwargs)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \query.py", line 1490, in insert_query
> >>    return query.get_compiler(using=using).execute_sql(return_id)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> >> \compiler.py", line 786, in execute_sql
> >>    cursor = super(SQLInsertCompiler, self).execute_sql(None)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> >> \compiler.py", line 730, in execute_sql
> >>    cursor.execute(sql, params)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends
> >> \sqlite3\base.py", line 221, in execute
> >>    return Database.Cursor.execute(self, query, params)
> >> DatabaseError: no such table: auth_user
>
> >> --
> >> 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 
> >> athttp://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 django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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 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: Bug with testing framework when not using contrib.auth

[Yo-Yo Ma]

I've been using CookieStorage (for less DB usage). Us that frowned
upon nowadays, in favor of the DB backend?

On Nov 2, 6:26 pm, Russell Keith-Magee 
wrote:
> On Wed, Nov 3, 2010 at 8:18 AM, David P. Novakovic
>
>  wrote:
> > This is certainly an artifact of the fact that messages recent started
> > supporting anonymous messages. Previously it depended on auth.
>
> > I suspect you just need to open a ticket for this.
>
> Yes - this is oversight, not intention.
>
> contrib.messages depends on contrib.auth for reasons of backwards
> compatibility, but unless you're using the legacy fallback storage
> mechanism, that dependency doesn't exist in practice. You're the first
> person to report this dependency as a practical concern.
>
> I suspect we'll need to crack out some of the new unittest2 features
> to fix this; skipping the user_messages tests unless contrib.auth is
> available.
>
> Yours,
> Russ Magee %-)
>
>
>
> > On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma  wrote:
> >> I have a large application that doesn't user contrib.auth, and when I
> >> run `manage.py test` I get a slough of 35 errors, all of which are
> >> DatabaseError: no such table: auth_user (differing Tracebacks for
> >> each). I don't have any actual tests yet, just the SimpleTest that
> >> comes free in tests.py. INSTALLED_APPS is:
>
> >>    'django.contrib.sessions',
> >>    'django.contrib.messages',
> >>    'myproject.myapp',  # Plus 8 more custom apps omitted.
>
> >> With this bug, Django's testing framework is seemingly coupled to a
> >> contrib app.
>
> >> One of the Tracebacks:
>
> >> ==
> >> ERROR: test_add
> >> (django.contrib.messages.tests.user_messages.UserMessagesTest)
> >> --
> >> Traceback (most recent call last):
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\contrib
> >> \messages\tests\user_messages.py", line 13, in setUp
> >>    self.user = User.objects.create(username='tester')
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \manager.py", line 138, in create
> >>    return self.get_query_set().create(**kwargs)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \query.py", line 351, in create
> >>    obj.save(force_insert=True, using=self.db)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \base.py", line 452, in save
> >>    self.save_base(using=using, force_insert=force_insert,
> >> force_update=force_update)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \base.py", line 545, in save_base
> >>    result = manager._insert(values, return_id=update_pk, using=using)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \manager.py", line 195, in _insert
> >>    return insert_query(self.model, values, **kwargs)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> >> \query.py", line 1490, in insert_query
> >>    return query.get_compiler(using=using).execute_sql(return_id)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> >> \compiler.py", line 786, in execute_sql
> >>    cursor = super(SQLInsertCompiler, self).execute_sql(None)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> >> \compiler.py", line 730, in execute_sql
> >>    cursor.execute(sql, params)
> >>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends
> >> \sqlite3\base.py", line 221, in execute
> >>    return Database.Cursor.execute(self, query, params)
> >> DatabaseError: no such table: auth_user
>
> >> --
> >> 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 
> >> athttp://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 django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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 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: Ticket #7817: Extending "with" and "include" tags.

[burc...@gmail.com]

Hi Jannis,

On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel  wrote:
> On 27.10.2010, at 09:46, SmileyChris wrote:
>
>> On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
>>> I would like to bring this up again, because this is something that
>>> would really improve readability of my templates. I'm mainly
>>> interested in ticket #7817 (the include tag changes), but extending
>>> "with" tag (ticket 9456) would keep things consistent.
>>
>> Here's a link to the ticket for the lazier ones among us:
>> http://code.djangoproject.com/ticket/7817
>>
>> The main decision which needs to be made is one of syntax.
>>
>> The current proposal uses:
>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>> but this introduces an inconsistency with the {% with %} tag.
>
> I'm feeling strongly against moving from the "value as name" to the 
> "name=value" notation, since I think the former is actually more readable 
> than the latter for the targetted audience (template authors).

If you are not asking real people, it's a speculation anyway.

I'm also target audience (since I write initial Django templates
structure for HTML from designer), even though I'm a programmer.
I think there are even more programmers than designers that use django
templates.
Our designer don't care at all, because she will just use any solution
to do her job.
So of two people, one voted for "=", second abstained from voting.

I think for most people "=" is slightly better than "as" because:
 - All of them had math classes at school and they know "=" already.
 - Not every Django template author knows English.

"Slightly" because:
   - they have to spend some minutes to understand "how the tag works"
anyway, and it's much more time than they would think of "what does
'=' do here" or "what does 'as' means here".
   - they just don't care. they didn't choose html, they didn't choose
css, they didn't choose django templates. it's so minor question.

Why I'm for "=":

I think, "and" + "as" are too verbose for this regular task.
They just make fast scanning through the template seeking for some
variables much harder and don't help at all.

>> Consistency would be nice, but I think this starts to look a bit
>> confusing, static tokens outnumbering actual functional ones:
>> {% include "name_snippet.html" with name as "Joe" and greeting as
>> "Hello" %}
>
> Well, I think that's actually not a bad notation at all (if using the correct 
> order :), so for #7817 I propose the following syntax (as analogously 
> proposed by #9456 for {% with %}):
>
> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>
>
> Jannis
>
> --
> 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.
>
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.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: staticfiles defaults broke my site

[Jannis Leidel]

On 02.11.2010, at 03:55, Carl Karsten wrote:

> I am not completely sure what is going on, but pretty sure the new
> staticfiles thing is colliding with my existing
> 
> urlpatterns += patterns('',
> (r'^static/(?P.*)$', 'django.contrib.staticfiles.views.serve',
>{'document_root': 'static/','show_indexes': True}))
> 
> That used to work, now I get:
> http://0.0.0.0:8080/static/
> "Page not found: /static/"  (not the typical 404 error page, which
> also seems like a bug, see below)
> 
> A stupid workaround fix is:
> STATICFILES_ROOT='foo'
> 
> Here is what the docs show:
> http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles
> STATICFILES_ROOT Default: '' (Empty string)
> STATICFILES_URL Default: '/static/'
> 
> 404 thing:
> 
> It does return a 404, but not the 404 page.

That's mostly a backwards compatibility issue, since the static serve view 
(called through the old AdminMediaHandler) in 1.2.X and earlier raised a blank 
PermissionDenied error if accessed. I think showing here a proper 404 page 
isn't a bad idea though.

> c...@dc10:~/temp$ curl -v http://0.0.0.0:8080/static/
> * About to connect() to 0.0.0.0 port 8080 (#0)
> *   Trying 0.0.0.0... connected
> * Connected to 0.0.0.0 (0.0.0.0) port 8080 (#0)
>> GET /static/ HTTP/1.1
>> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o 
>> zlib/1.2.3.4 libidn/1.18
>> Host: 0.0.0.0:8080
>> Accept: */*
>> 
> * HTTP 1.0, assume close after body
> < HTTP/1.0 404 NOT FOUND
> < Date: Tue, 02 Nov 2010 02:52:58 GMT
> < Server: WSGIServer/0.1 Python/2.6.6
> < Content-type: text/plain
> < Content-Length: 24
> <
> * Closing connection #0
> Page not found: /static/



-- 
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.