Re: How to show the template reserved keyword on html.

[Morris]

HI Karen,

Thanks for your reminding. I have moved to django-users.

On Feb 20, 2:51 pm, Karen Tracey  wrote:
> Please ask questions about using Django on django-users. The topic of this
> list is the development of Django itself.
>
> Karen

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

Re: How to show the template reserved keyword on html.

[Karen Tracey]

Please ask questions about using Django on django-users. The topic of this
list is the development of Django itself.

Karen

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

How to show the template reserved keyword on html.

[Morris]

Hi all,

   I would like to write some django note via template. I tried to
show ""{{ sample }}"" on my website, but it's empty. I think django
think it's a variable name.

   So, how to show {{ sample }} ? On the other hand, how to show
template reserved word?

   Thanks a lot.

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

Re: Revisiting multiline tags

[Stephen Burrows]

> Personally, I would like to be able to see a tag all at once (that is
> without scrolling), even though I might have to scroll to get to the
> start of it.  I believe this improves readability of the template. My
> specific use case is with include tags with long template paths and
> added context variables.

Most text editors let you enable line-wrapping... though this isn't as
"elegant" as multi-line tags, it would let you see everything without
scrolling.

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

Re: Revisiting multiline tags

[Adrian Holovaty]

On Sat, Feb 18, 2012 at 12:04 AM, Glenn Washburn
 wrote:
> I'd like to reopen discussion on the multiline tag issue (see:
> https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.

Putting on my BDFL cap...I'd prefer not to implement multi-line tags,
purely for aesthetic reasons. It's much easier to visually parse
single-line tags, and multi-line tags look ugly.

Granted, there are some situations in which multi-line tags are an
improvement (see the example by h3 in this thread), but those are
relatively rare and don't make it worth it to me.

Adrian

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

Re: Revisiting multiline tags

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Glenn,

On 02/19/2012 07:06 PM, Glenn Washburn wrote:
> Very brief I might add.  He only alludes to one technical reason
> saying: "error trapping can occur much earlier".  I'm trying to
> understand what is meant by this as well.  I don't see how my proposed
> change affects error handling in anyway.  What problems are caused by
> my change?  I'm actually very interested in this as I'm likely going to
> be using this.

Not sure; it seems the "many discussions" of this happened before I was
around.

> I hope I'm not being too demanding by desiring a documented list of
> reasons why this is a bad idea.  I've search the groups and not found
> anything significant related to this.  Where was it discussed an are
> there logs? (was it on irc?)

I'm interested as well; I don't see obvious issues with the approach in
your patch. It may in fact be that template lexing has changed enough in
the last few years to make this simpler now than it was then.

> Is there a way we can move forward on this?

Technically speaking, the way forward would be to open a ticket and
attach a patch with tests and docs (in any case, I would do this rather
than consider reopening #3888 - it's too muddled with reference to
possible specific handling of comments). More importantly, though, given
the history here, would be to get a comment from a core developer more
familiar than I am with that history; and perhaps one with a stronger
opinion on the issue. So posting here was the right thing to do - now
the right thing is probably to wait for a bit.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9Btq4ACgkQ8W4rlRKtE2dfMACcCzIFAPiXQLbnEx5NyE4D6zDG
SyAAnjzHSKxJWLSgiiuSN1pyznjgzcuY
=cJ44
-END PGP SIGNATURE-

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

Re: Revisiting multiline tags

[Glenn Washburn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 19 Feb 2012 10:01:06 -0700
Carl Meyer  wrote:

> Here's a discussion linked from #3888 in which Malcolm lays out in
> brief why multiline tags have been rejected:
> https://groups.google.com/forum/?fromgroups#!topic/django-developers/A17TJWd3YJU

Very brief I might add.  He only alludes to one technical reason
saying: "error trapping can occur much earlier".  I'm trying to
understand what is meant by this as well.  I don't see how my proposed
change affects error handling in anyway.  What problems are caused by
my change?  I'm actually very interested in this as I'm likely going to
be using this.

I hope I'm not being too demanding by desiring a documented list of
reasons why this is a bad idea.  I've search the groups and not found
anything significant related to this.  Where was it discussed an are
there logs? (was it on irc?)

> There is indeed precedent for wontfix decisions being reversed, but
> this isn't one. The lexing bug revealed in #3888 that caused
> multiline {# #} to sorta kinda work in a broken way had its own
> ticket opened (#4164) and was fixed. In any recent Django, including
> 1.3.1 and 1.4 beta, multiline {# #} does not work at all.

Thanks Carl for pointing that out; I hadn't read that issue close
enough.  And, you're correct I am seeing that multiline {# #} are not
working in 1.3.1.

Personally, I would like to be able to see a tag all at once (that is
without scrolling), even though I might have to scroll to get to the
start of it.  I believe this improves readability of the template. My
specific use case is with include tags with long template paths and
added context variables.

Is there a way we can move forward on this?

Glenn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPQaqyAAoJEEPj94mUXoYs61oH/iGuxhABRXF9LT0qK1Kd+FHC
GH7LXijmGEsCo5KUZWmNCir3kKsi9yMJXgqt6oh7+TLj0MIpsD2PM1o9WgJwwxOz
Kbd2DYrq5jvhSPyufVaJbjgTtgLap+PtcdS5k5hJRq/gMDPbQzM8PKxbM3/Mzulo
prj5goCbVX+3NMVW7KrhnMcL3xQq8tB7cCY3azuOYCpAam8/SwFqzlx9sKdxtjbo
lGgaYPK8oi5TslQjEOvtffFXYv5yCuAAZmfFHjByr5eWYTcDJYQP7I/soQqKpkAS
fcUt74MpIODnKiiFAMroGdRfjXa7QhlxTaD6SB6kz1u7UDcM9WGFuzyajOnlzFo=
=X2ww
-END PGP SIGNATURE-

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

Could prefetch_related be modified to utilize select_related for ForeignKey relations?

[Yo-Yo Ma]

Speaking with regards to the ORM method documented at
https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related

Of course, ``prefetch_related`` uses a Pythonic join to attach reverse-
related objects and avoids the N+1 queries problem, which of course is
great. However, if you use it like this:

>>> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type')

It doesn't seem to take advantage ``select_related`` (assuming that
``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead
sends a separate query for ``Topping`` and ``ToppingType``, joining
them in Python. Is it feasible to modify ``prefetch_related`` use
``select_related`` when it encounters a ``ForeignKey``?

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

Re: Revisiting multiline tags

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/19/2012 10:20 AM, Torsten Bronger wrote:
> I've made the same observations as in the parallel posting: I18n
> becomes awkward with single-line tags.  We have dozens of lines like
> 
> {% blocktrans with originator=entry.originator|get_really_full_name:"mailto" 
> link=entry.get_metadata.link task_id=entry.task.id 
> process_name=entry.task.process_class|contenttype_name %}

Acknowledged. That would be a lot nicer split across multiple lines.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9BM/AACgkQ8W4rlRKtE2cXkACgkRuL11edpgUB7MfRyPjuOyS7
jkAAoL4JW+CDFsryZb+UkjCizKxlMYs4
=U4+9
-END PGP SIGNATURE-

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

Re: Revisiting multiline tags

[colinta]

Here here!  I think the django templating language is unnecessarily
restrictive in many places, but this one *really* boggles me.  Give me
back my whitespace!

(please)

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

Re: Revisiting multiline tags

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/17/2012 11:04 PM, Glenn Washburn wrote:
> I'd like to reopen discussion on the multiline tag issue (see:
> https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.

Here's a discussion linked from #3888 in which Malcolm lays out in brief
why multiline tags have been rejected:
https://groups.google.com/forum/?fromgroups#!topic/django-developers/A17TJWd3YJU

Personally I'd be -0 at worst on multiline tags, but I also don't see
any compelling use-cases. I think tags on a single line are
significantly easier to parse visually.

> Its interesting to note that
> https://code.djangoproject.com/ticket/3888, which is referenced in the
> issue, is also closed as "won't fix", but appears to be allowed in
> 1.3.1.  So there is a precedent for "won't fix" issues being included.

There is indeed precedent for wontfix decisions being reversed, but this
isn't one. The lexing bug revealed in #3888 that caused multiline {# #}
to sorta kinda work in a broken way had its own ticket opened (#4164)
and was fixed. In any recent Django, including 1.3.1 and 1.4 beta,
multiline {# #} does not work at all.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9BKtIACgkQ8W4rlRKtE2fnIACg0TxHHzG3rFKbRSkloeZWopmQ
3h8AoNEfygapod43tk3o6ypN2RKLAcGo
=9Xhx
-END PGP SIGNATURE-

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

Re: Django 1.4: call for release blockers

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/19/2012 09:40 AM, Carl Meyer wrote:
> On 02/18/2012 05:37 AM, Anssi Kääriäinen wrote:
>> The second one is about .iterator() and .prefetch_related()
>> interoperability. They are mutually exclusive (you need to fetch all
>> the objects before you can do prefetch. However, .iterator() says do
>> not fetch all the objects in one go...). There are basically three
>> ways forward: raise an error, favor .iterator() (current behavior) or
>> favor .prefetch_related().
> 
>> I think each one has some merit, and this is mostly bike-shedding.
>> However, if you have good reasons for one of the options it would be
>> good to hear them now. I would prefer either error or doing the
>> prefetch even when iterator is used. As I don't recall ever actually
>> using .iterator() in production I have no strong opinions. The ticket
>> is #17668.
> 
> I don't have a real strong opinion here either, but I think this rarity
> of usage of .iterator() is an argument for favoring it. In my
> experience, if you are bothering to use .iterator() it's because you
> really know you need it; you are fetching a ton of items and loading
> them all at once might run your server out of memory. Whereas the
> consequence of ignoring prefetch_related is just extra SQL queries -
> bad, but less likely to be catastrophic.
> 
> That's all kind of handwavy, but in the absence of good hard reasons in
> either direction, it's the best I've got :-)

Actually, another reason to favor .iterator is that it's a terminal
clause. So in any situation where iterator and prefetch_related are both
used, iterator must have been used last. So favoring .iterator favors
the most recent request, and in the hypothetical "you got the queryset
from some other library" situation, favors the integrating developer's
request.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9BJ3gACgkQ8W4rlRKtE2djBwCeIQiWCfmazZ2clfkkrCcEqV6C
g48An3q2IowQsgW5Q2zaYkDsNuY4BQRM
=SeV6
-END PGP SIGNATURE-

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

Re: Django 1.4: call for release blockers

[Carl Meyer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Anssi,

On 02/18/2012 05:37 AM, Anssi Kääriäinen wrote:
> The second one is about .iterator() and .prefetch_related()
> interoperability. They are mutually exclusive (you need to fetch all
> the objects before you can do prefetch. However, .iterator() says do
> not fetch all the objects in one go...). There are basically three
> ways forward: raise an error, favor .iterator() (current behavior) or
> favor .prefetch_related().
> 
> I think each one has some merit, and this is mostly bike-shedding.
> However, if you have good reasons for one of the options it would be
> good to hear them now. I would prefer either error or doing the
> prefetch even when iterator is used. As I don't recall ever actually
> using .iterator() in production I have no strong opinions. The ticket
> is #17668.

I don't have a real strong opinion here either, but I think this rarity
of usage of .iterator() is an argument for favoring it. In my
experience, if you are bothering to use .iterator() it's because you
really know you need it; you are fetching a ton of items and loading
them all at once might run your server out of memory. Whereas the
consequence of ignoring prefetch_related is just extra SQL queries -
bad, but less likely to be catastrophic.

That's all kind of handwavy, but in the absence of good hard reasons in
either direction, it's the best I've got :-)

Really, silently ignoring either one gives me a bit of a bad taste. I
understand Luke's reasoning for not raising an error; you might not
control the whole queryset construction chain, and unpredictable errors
are bad. But I wish there were some way we could alert the developer of
the situation.

I guess anyone who really needs the prefetch_related is probably
monitoring their SQL queries, and is likely to notice the extra SQL
queries pretty quickly.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9BJeUACgkQ8W4rlRKtE2fcjgCbBudTE6UjRCTRashf6mZ5PNzI
toUAnRIatUAfQVw33mlbAp6W3Mx0ofHg
=UCkj
-END PGP SIGNATURE-

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

Re: Class-based view decorators

[Luke Plant]

On 17/02/12 18:04, Tobia Conforto wrote:
> Hello
> 
> As a happy user of the class-based views, I wrote a couple of
> higher-level decorators to make it easy to apply all the standard
> decorators to them.
> 

> The first is an updated version of method_decorator, made to accept
> additional arguments and pass them to the original decorator:

I don't have time to comment on the other things, but I think this bit -
essentially mixing up decorators and decorator generators - is a bad
idea. The smell is apparent in the docstring:

"""
Does not support decorators with call but without arguments: @my_dec()
"""

And my past experience has shown that this is a bad thing. It can get
diabolical if you try to apply some further higher level thing to
method_decorator itself.

Here is what is sometimes caused by attempting the convenience of
flexibility in the calling convention:

https://code.djangoproject.com/browser/django/trunk/django/views/decorators/cache.py?rev=17484#L7

Regards,

Luke

-- 
"I asked mom if I was a gifted child. She said they certainly
wouldn't have paid for me." (Calvin and Hobbes)

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