Re: Revisiting multiline tags

[Stephan Jaensch]

>> 1) It's an easy fix.
>> 2) It's backwards compatible.
>> 3) It has no impact on performance.
>> 4) LOTS of people want it.
>> 
>> and most importantly
>> 
>> 5) We could stop asking for it.
>> 
>> This issue is such an easy "sure, why not!?"
>> 
>> Please, O benevolent dictators, listen to the populous, and heed their
>> cry.
> 
> I can certainly appreciate the reasons why those asking for this change would 
> like to see the change made, but please don't attempt to characterize this 
> thread as clear and overwhelming support for change.
> 
> This thread contains 6 people expressing support for this change, and 2 
> against (a BDFL, a core developer) -- and you can add me to the -0 list. 
> There are over 6000 subscribers to django-developers. I put it to you that 
> the vast majority of people haven't expressed an opinion -- and many of those 
> haven't expressed an opinion because they're happy with (or indifferent to) 
> the status quo, and a BDFL has already indicated that the status quo is his 
> preferred option.

You asked for it, so here is my +1.

> This is also the first time the issue has been raised on django-dev for some 
> time -- I can't even remember the last time the subject was raised. If this 
> is such a demand of the populous, why isn't it a regular topic of discussion 
> on django-dev? 

Because the Django community is extremely nice and well-behaved...? :) I too 
was unhappy with the decision, but didn't feel it was important enough to post 
in this thread. That doesn't mean I wouldn't appreciate multiline tags.

> Finally, your arguments in favor of making this change are almost entirely 
> technical -- easy fix, backwards compatible, no performance hit. However, 
> you've missed the non-technical aspects -- that introducing multiline tags 
> would fundamentally change the flavor of Django templates. Part of the job of 
> the BDFLs is to make aesthetic choices. As indicated by Adrian in his 
> response, this is largely an aesthetic decision on his part. Aesthetic 
> choices aren't always popular, and almost by definition won't make everyone 
> happy, but they are an essential part of what gives Django it's distinctive 
> flavor. 

Well, and you are really making the non-technical argument for the supporters, 
aren't you? If multiline tags would fundamentally change the flavor of Django 
templates, it would mean that suddenly people everywhere would start using 
them, massively. This would mean there is overwhelming demand for them. But if 
people do only use them in the cases where it's appropriate (e.g. the dreaded 
trans tag, multi-line comments and so forth) then it doesn't change much of 
anything and just makes templates more readable.

I understand this is an aesthetic decision. I just wish to point out that you 
can't make the argument that nobody wants it and that it would also have a big 
impact.

Cheers,
Stephan

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

Django and dictionary ordering

[Vinay Sajip]

Is there any work going on with regard to making Django more resilient
in the face of changes to dictionary ordering? I know there has been
discussion about the hash collision issue last December, but I'm
unable to find a summary of the official Django position on this. Can
someone please point me to it? My Google-fu may have deserted me.

Following recent changes to the in-development Python 3.3, several
dozen Django tests are failing, apparently because of changes to
dictionary hashing and hence key order. Some examples:

==
FAIL: test_proxy_model_included
(regressiontests.fixtures_regress.tests.TestFixtures)
--
Traceback (most recent call last):
  File "/Users/administrator/projects/django3/tests/regressiontests/
fixtures_regress/tests.py", line 363, in test_proxy_model_included
% widget.pk
AssertionError: '[{"model": "fixtures_regress.widget", "fields":
{"name": "grommet"}, "pk": 1}]' [truncated]... != '[{"pk": 1, "model":
"fixtures_regress.widget", "fields": {"name":
"grommet"}}]' [truncated]...
- [{"model": "fixtures_regress.widget", "fields": {"name": "grommet"},
"pk": 1}]
?
-
+ [{"pk": 1, "model": "fixtures_regress.widget", "fields": {"name":
"grommet"}}]
?   +


==
FAIL: test_basic_processing_in_view
(regressiontests.forms.tests.forms.FormsTestCase)
--
Traceback (most recent call last):
  File "/Users/administrator/projects/django3/tests/regressiontests/
forms/tests/forms.py", line 1527, in test_basic_processing_in_view
py3_prefix("VALID: {'username': %(_)s'adrian', 'password1': %
(_)s'secret', 'password2': %(_)s'secret'}"))
  File "/Users/administrator/projects/django3/django/test/
testcases.py", line 429, in assertHTMLEqual
self.fail(self._formatMessage(msg, standardMsg))
AssertionError: VALID: {'username': 'adrian', 'password2': 'secret',
'password1': 'secret'} != VALID: {'username': 'adrian', 'password1':
'secret', 'password2': 'secret'}
- VALID: {'username': 'adrian', 'password2': 'secret', 'password1':
'secret'}
+ VALID: {'username': 'adrian', 'password1': 'secret', 'password2':
'secret'}

There are no corresponding failures with Python 3.2. The Django 3.x
branch is pretty up to date with trunk.

Regards,

Vinay Sajip

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

[Bradley Ayers]

On 24/02/2012, at 7:01 PM, Stephan Jaensch  wrote:

>>> 1) It's an easy fix.
>>> 2) It's backwards compatible.
>>> 3) It has no impact on performance.
>>> 4) LOTS of people want it.
>>> 
>>> and most importantly
>>> 
>>> 5) We could stop asking for it.
>>> 
>>> This issue is such an easy "sure, why not!?"
>>> 
>>> Please, O benevolent dictators, listen to the populous, and heed their
>>> cry.
>> 
>> I can certainly appreciate the reasons why those asking for this change 
>> would like to see the change made, but please don't attempt to characterize 
>> this thread as clear and overwhelming support for change.
>> 
>> This thread contains 6 people expressing support for this change, and 2 
>> against (a BDFL, a core developer) -- and you can add me to the -0 list. 
>> There are over 6000 subscribers to django-developers. I put it to you that 
>> the vast majority of people haven't expressed an opinion -- and many of 
>> those haven't expressed an opinion because they're happy with (or 
>> indifferent to) the status quo, and a BDFL has already indicated that the 
>> status quo is his preferred option.
> 
> You asked for it, so here is my +1.
> 
>> This is also the first time the issue has been raised on django-dev for some 
>> time -- I can't even remember the last time the subject was raised. If this 
>> is such a demand of the populous, why isn't it a regular topic of discussion 
>> on django-dev? 
> 
> Because the Django community is extremely nice and well-behaved...? :) I too 
> was unhappy with the decision, but didn't feel it was important enough to 
> post in this thread. That doesn't mean I wouldn't appreciate multiline tags.
> 
>> Finally, your arguments in favor of making this change are almost entirely 
>> technical -- easy fix, backwards compatible, no performance hit. However, 
>> you've missed the non-technical aspects -- that introducing multiline tags 
>> would fundamentally change the flavor of Django templates. Part of the job 
>> of the BDFLs is to make aesthetic choices. As indicated by Adrian in his 
>> response, this is largely an aesthetic decision on his part. Aesthetic 
>> choices aren't always popular, and almost by definition won't make everyone 
>> happy, but they are an essential part of what gives Django it's distinctive 
>> flavor. 
> 
> Well, and you are really making the non-technical argument for the 
> supporters, aren't you? If multiline tags would fundamentally change the 
> flavor of Django templates, it would mean that suddenly people everywhere 
> would start using them, massively. This would mean there is overwhelming 
> demand for them. But if people do only use them in the cases where it's 
> appropriate (e.g. the dreaded trans tag, multi-line comments and so forth) 
> then it doesn't change much of anything and just makes templates more 
> readable.
> 
> I understand this is an aesthetic decision. I just wish to point out that you 
> can't make the argument that nobody wants it and that it would also have a 
> big impact.
> 
> Cheers,
> Stephan

In the interest of making the wider community opinion heard, I too am +1 on 
this, my feeling is exactly the same as 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-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

[Shawn Milochik]

On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  wrote:
>
> In the interest of making the wider community opinion heard, I too am +1 on 
> this, my feeling is exactly the same as Stephen.
>
> --

+1

I understand that a BDFL has spoken and this change isn't going to
happen. I hate to add to the noise, but since the argument from
popularity fallacy has been invoked, I feel the need to point out that
many of us didn't bother to weigh in because we didn't choose to add
to the noise. Especially after the case was so well-made by others --
it didn't seem necessary.

Shawn

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

[Chris Northwood]

A +1 from me too, I've really felt the pain on this when doing i18n
templates, I understand the aesthetics, but the aesthetics of
obscenely long tags is also bad imo...

On 24 February 2012 09:23, Shawn Milochik  wrote:
> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  
> wrote:
>>
>> In the interest of making the wider community opinion heard, I too am +1 on 
>> this, my feeling is exactly the same as Stephen.
>>
>> --
>
> +1
>
> I understand that a BDFL has spoken and this change isn't going to
> happen. I hate to add to the noise, but since the argument from
> popularity fallacy has been invoked, I feel the need to point out that
> many of us didn't bother to weigh in because we didn't choose to add
> to the noise. Especially after the case was so well-made by others --
> it didn't seem necessary.
>
> Shawn
>
> --
> 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 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 and dictionary ordering

[Paul McMillan]

The official Django position on the Python hash randomization issue is
that this Python bug has been fixed in Python. Users of Django should
explicitly enable hash randomization for versions of Python below 3.3.
We'll probably make a formal announcement and writeup for how to do
this once the changes have trickled down into more general
distribution channels. Users who cannot enable randomization or cannot
patch their versions of Python are advised to limit the size of
requests and the number of allowed parameters per request in their
webserver to the smallest practicable value for their use case, and
strictly limit the maximum runtime of any given process.

Any failures of the Django test suite which are caused specifically by
this randomization change are bugs. Tickets and patches are welcome.

-Paul

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

[Luke Granger-Brown]

+1 from me too - I've used {# #} across line boundaries before and wondered
why it didn't work, since it didn't seem especially clear that this doesn't
work nor why it doesn't work - I'd just substituted  for the
obvious and eventually just deleted the offending HTML.
On Feb 24, 2012 9:30 AM, "Chris Northwood"  wrote:

> A +1 from me too, I've really felt the pain on this when doing i18n
> templates, I understand the aesthetics, but the aesthetics of
> obscenely long tags is also bad imo...
>
> On 24 February 2012 09:23, Shawn Milochik  wrote:
> > On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers 
> wrote:
> >>
> >> In the interest of making the wider community opinion heard, I too am
> +1 on this, my feeling is exactly the same as Stephen.
> >>
> >> --
> >
> > +1
> >
> > I understand that a BDFL has spoken and this change isn't going to
> > happen. I hate to add to the noise, but since the argument from
> > popularity fallacy has been invoked, I feel the need to point out that
> > many of us didn't bother to weigh in because we didn't choose to add
> > to the noise. Especially after the case was so well-made by others --
> > it didn't seem necessary.
> >
> > Shawn
> >
> > --
> > 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 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 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

[Jonas H.]

On 02/24/2012 10:01 AM, Stephan Jaensch wrote:

This thread contains 6 people expressing support for this change, and 2 against 
(a BDFL, a core developer) -- and you can add me to the -0 list. There are over 
6000 subscribers to django-developers. I put it to you that the vast majority 
of people haven't expressed an opinion -- and many of those haven't expressed 
an opinion because they're happy with (or indifferent to) the status quo, and a 
BDFL has already indicated that the status quo is his preferred option.


You asked for it, so here is my +1.


+1 from me too.

Maybe someone could invent an official feature voting tool? :-)

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

[Ivan Kharlamov]

On 02/24/2012 01:29 PM, Chris Northwood wrote:
> A +1 from me too, I've really felt the pain on this when doing i18n
> templates, I understand the aesthetics, but the aesthetics of
> obscenely long tags is also bad imo...
> 
> On 24 February 2012 09:23, Shawn Milochik  wrote:
>> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers  
>> wrote:
>>>
>>> In the interest of making the wider community opinion heard, I too am +1 on 
>>> this, my feeling is exactly the same as Stephen.
>>>
>>> --
>>
>> +1
>>
>> I understand that a BDFL has spoken and this change isn't going to
>> happen. I hate to add to the noise, but since the argument from
>> popularity fallacy has been invoked, I feel the need to point out that
>> many of us didn't bother to weigh in because we didn't choose to add
>> to the noise. Especially after the case was so well-made by others --
>> it didn't seem necessary.
>>
>> Shawn
>>
>> --
>> 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.
>>
> 

+1

If you are against truly multiline tags, consider supporting a line
continuation character sequence (something like backslash in most of the
programming languages) inside tags, which a poor template author can use
as a last resort to make his code readable.

In the docs, discourage people from going multiline. Highlight that it
is the last thing to do (like PEP does).

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

django 1.4b + mysql + boolean fields

[Tomasz Kloc]

Hello,

I've changed my database from postgresql to mysql. I have never used 
mysql in django projects before, so it was surprising to me when i saw 
0/1 values instead of True/False in boolean fields. It wasn't an issue 
until i upgraded django from 1.3.1 to 1.4b.  After that, all boolean 
fields in admin interface are checked (in edit mode). They are rendered as:


name="checkbox_filter" checked="checked">


i've looked into forms.widgets.CheckboxInput in both django versions and 
noticed some logic changes when checking value:


(1.3.1)


def __init__(self, attrs=None, check_test=bool):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
self.check_test = check_test


(1.4b)



def __init__(self, attrs=None, check_test=None):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
if check_test is None:
self.check_test = lambda v: not (v is False or v is None 
or v == '')

else:
self.check_test = check_test


in this case "0" is treated as True.

Is this a bug?

regards,
tomasz kloc



--
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.4b + mysql + boolean fields

[Tomasz Kloc]

Ticket with change described below: 
https://code.djangoproject.com/ticket/17114


I've also found that since Django 1.2 
(https://docs.djangoproject.com/en/dev/releases/1.2/#booleanfield-on-mysql) 
booleans in mysql backend should be returned as True/False, but i still 
get ints values.


In [7]: AuctionCategoryCustomField.objects.all()[0].enable_search_filter
Out[7]: 1

environment:
In [6]: sys.version
Out[6]: '2.6.6 (r266:84292, Dec 26 2010, 22:31:48) \n[GCC 4.4.5]'

In [7]: django.VERSION
Out[7]: (1, 3, 1, 'final', 0)

On 24.02.2012 11:00, Tomasz Kloc wrote:

Hello,

I've changed my database from postgresql to mysql. I have never used 
mysql in django projects before, so it was surprising to me when i saw 
0/1 values instead of True/False in boolean fields. It wasn't an issue 
until i upgraded django from 1.3.1 to 1.4b.  After that, all boolean 
fields in admin interface are checked (in edit mode). They are 
rendered as:


name="checkbox_filter" checked="checked">


i've looked into forms.widgets.CheckboxInput in both django versions 
and noticed some logic changes when checking value:


(1.3.1)


def __init__(self, attrs=None, check_test=bool):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
self.check_test = check_test


(1.4b)



def __init__(self, attrs=None, check_test=None):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
if check_test is None:
self.check_test = lambda v: not (v is False or v is None 
or v == '')

else:
self.check_test = check_test


in this case "0" is treated as True.

Is this a bug?

regards,
tomasz kloc





--
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.4b + mysql + boolean fields

[Tomasz Kloc]

The problem was caused by django.contrib.gis.db.backends.mysql backend. 
It has own backend implementation which returns booleans as integers (it 
was fixed for 'core' mysql backend in 
https://code.djangoproject.com/ticket/13293 )


I think it's a bug which will afect some users after upgrading to django 
1.4 - in my opinion quite serious.


Any comments before creating a ticket?


On 24.02.2012 11:25, Tomasz Kloc wrote:
Ticket with change described below: 
https://code.djangoproject.com/ticket/17114


I've also found that since Django 1.2 
(https://docs.djangoproject.com/en/dev/releases/1.2/#booleanfield-on-mysql) 
booleans in mysql backend should be returned as True/False, but i 
still get ints values.


In [7]: AuctionCategoryCustomField.objects.all()[0].enable_search_filter
Out[7]: 1

environment:
In [6]: sys.version
Out[6]: '2.6.6 (r266:84292, Dec 26 2010, 22:31:48) \n[GCC 4.4.5]'

In [7]: django.VERSION
Out[7]: (1, 3, 1, 'final', 0)

On 24.02.2012 11:00, Tomasz Kloc wrote:

Hello,

I've changed my database from postgresql to mysql. I have never used 
mysql in django projects before, so it was surprising to me when i 
saw 0/1 values instead of True/False in boolean fields. It wasn't an 
issue until i upgraded django from 1.3.1 to 1.4b.  After that, all 
boolean fields in admin interface are checked (in edit mode). They 
are rendered as:


name="checkbox_filter" checked="checked">


i've looked into forms.widgets.CheckboxInput in both django versions 
and noticed some logic changes when checking value:


(1.3.1)


def __init__(self, attrs=None, check_test=bool):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
self.check_test = check_test


(1.4b)



def __init__(self, attrs=None, check_test=None):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
if check_test is None:
self.check_test = lambda v: not (v is False or v is None 
or v == '')

else:
self.check_test = check_test


in this case "0" is treated as True.

Is this a bug?

regards,
tomasz kloc





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

[Jonathan French]

Since we're consensus building or whatever the fancy term is, another +1.

Mainly for comments, since {# #} is far, far more readable than {% comment
%}{% endcomment %} even with syntax highlighting, but also for other tags
too, particularly long i18n ones -- or even relatively short ones where you
have complex nested HTML and have indented yourself against a wall, but are
coding to a style which insists on a hard right margin, no exceptions.

Soft word wrapping isn't the best option, since you can produce a much
clearer result through manual line breaks and alignment than your editor
can through wrapping at the last word on the line.

This is a tiny change which would make many people's lives easier. I'm very
surprised at Django, with the whole "batteries included" thing,
deliberately withholding a feature for aesthetic reasons. When did you turn
into GNOME? ;-) Please reconsider.

- ojno

On 24 February 2012 10:29, Ivan Kharlamov  wrote:

> On 02/24/2012 01:29 PM, Chris Northwood wrote:
> > A +1 from me too, I've really felt the pain on this when doing i18n
> > templates, I understand the aesthetics, but the aesthetics of
> > obscenely long tags is also bad imo...
> >
> > On 24 February 2012 09:23, Shawn Milochik  wrote:
> >> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers 
> wrote:
> >>>
> >>> In the interest of making the wider community opinion heard, I too am
> +1 on this, my feeling is exactly the same as Stephen.
> >>>
> >>> --
> >>
> >> +1
> >>
> >> I understand that a BDFL has spoken and this change isn't going to
> >> happen. I hate to add to the noise, but since the argument from
> >> popularity fallacy has been invoked, I feel the need to point out that
> >> many of us didn't bother to weigh in because we didn't choose to add
> >> to the noise. Especially after the case was so well-made by others --
> >> it didn't seem necessary.
> >>
> >> Shawn
> >>
> >> --
> >> 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.
> >>
> >
>
> +1
>
> If you are against truly multiline tags, consider supporting a line
> continuation character sequence (something like backslash in most of the
> programming languages) inside tags, which a poor template author can use
> as a last resort to make his code readable.
>
> In the docs, discourage people from going multiline. Highlight that it
> is the last thing to do (like PEP does).
>
> --
> 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 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.

Newline stripping in templates: the dnl way

[Tobia]

Hi all,
regarding issue #2594 "Template system should handle whitespace
better" explaining the need for some kind of (optional) whitespace
stripping from the output of templates, I've been looking at the
proposed solutions and compared them to other template and macro
engines.

In particular, a historical but still widely used and general-purpose
macro engine is m4. Its own feature for controlled newline stripping
is the "dnl" reserved word, "Discard to Next Line." It works by
"chomping" all input until and including the next newline.

For example, to call a macro foo() without copying over the newline
that appears after the macro call in the template, a m4 programmer
would write:

foo('bar`, `whatever')dnl

An equivalent feature in Django templates would enable template
developers to strip newlines from specific lines, while keeping
backwards compatibility with existing templates.

So if the general idea is well-accepted, I propose the "{#" token. The
example from the issue would become:


{% for item in items %}{#
{{ item }}
{% endfor %}{#


It is already a reserved token in the template system, so it's not
going to break anything. The existing comment syntax {# ... #} is
already restricted to single-line comments, so there are no multi-line
comments that would break. Plus, I'd wager it could be implemented
quite efficiently.

What do you think?

Tobia

-- 
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 and dictionary ordering

[Łukasz Rekucki]

On 24 February 2012 10:31, Paul McMillan  wrote:
> The official Django position on the Python hash randomization issue is
> that this Python bug has been fixed in Python. Users of Django should
> explicitly enable hash randomization for versions of Python below 3.3.
> We'll probably make a formal announcement and writeup for how to do
> this once the changes have trickled down into more general
> distribution channels. Users who cannot enable randomization or cannot
> patch their versions of Python are advised to limit the size of
> requests and the number of allowed parameters per request in their
> webserver to the smallest practicable value for their use case, and
> strictly limit the maximum runtime of any given process.
>
> Any failures of the Django test suite which are caused specifically by
> this randomization change are bugs. Tickets and patches are welcome.
>
> -Paul
>

Just run the testsuite latest Python 2.6.8 and -R option:

Python 2.6.8rc1 (unknown, Feb 24 2012, 14:38:43)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin

with following results:

Ran 4613 tests in 822.943s

FAILED (failures=39, errors=1, skipped=109, expected failures=2)

It's a bare install, so there may be more within the skipped ones.
Most look harmless and only needs updating the testcases, so it
doesn't require specific order.

Created ticket https://code.djangoproject.com/ticket/17758 - I think
this should be a release blocker.

-- 
Ł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-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: Newline stripping in templates: the dnl way

[Tai Lee]

I definitely want to see a resolution to this issue. Django templates
when white space matters (e.g. plain text emails) are painful. But, I
don't think adding {# to the end of lines is easy to understand at a
glance, it doesn't even convey a hint of meaning like "dnl" does, but
either option is pretty ugly to my eyes.

I'd personally like to see a new template tag that will switch on the
new behaviour, and a deprecation path for this to become the default.

Cheers.
Tai.


On Feb 25, 1:10 am, Tobia  wrote:
> Hi all,
> regarding issue #2594 "Template system should handle whitespace
> better" explaining the need for some kind of (optional) whitespace
> stripping from the output of templates, I've been looking at the
> proposed solutions and compared them to other template and macro
> engines.
>
> In particular, a historical but still widely used and general-purpose
> macro engine is m4. Its own feature for controlled newline stripping
> is the "dnl" reserved word, "Discard to Next Line." It works by
> "chomping" all input until and including the next newline.
>
> For example, to call a macro foo() without copying over the newline
> that appears after the macro call in the template, a m4 programmer
> would write:
>
> foo('bar`, `whatever')dnl
>
> An equivalent feature in Django templates would enable template
> developers to strip newlines from specific lines, while keeping
> backwards compatibility with existing templates.
>
> So if the general idea is well-accepted, I propose the "{#" token. The
> example from the issue would become:
>
> 
> {% for item in items %}{#
>     {{ item }}
> {% endfor %}{#
> 
>
> It is already a reserved token in the template system, so it's not
> going to break anything. The existing comment syntax {# ... #} is
> already restricted to single-line comments, so there are no multi-line
> comments that would break. Plus, I'd wager it could be implemented
> quite efficiently.
>
> What do you think?
>
> Tobia

-- 
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: Newline stripping in templates: the dnl way

[Tom Evans]

On Fri, Feb 24, 2012 at 2:10 PM, Tobia  wrote:
> Hi all,
> regarding issue #2594 "Template system should handle whitespace
> better" explaining the need for some kind of (optional) whitespace
> stripping from the output of templates, I've been looking at the
> proposed solutions and compared them to other template and macro
> engines.
>
> In particular, a historical but still widely used and general-purpose
> macro engine is m4. Its own feature for controlled newline stripping
> is the "dnl" reserved word, "Discard to Next Line." It works by
> "chomping" all input until and including the next newline.
>
> For example, to call a macro foo() without copying over the newline
> that appears after the macro call in the template, a m4 programmer
> would write:
>
> foo('bar`, `whatever')dnl
>
> An equivalent feature in Django templates would enable template
> developers to strip newlines from specific lines, while keeping
> backwards compatibility with existing templates.
>
> So if the general idea is well-accepted, I propose the "{#" token. The
> example from the issue would become:
>
> 
> {% for item in items %}{#
>    {{ item }}
> {% endfor %}{#
> 
>
> It is already a reserved token in the template system, so it's not
> going to break anything. The existing comment syntax {# ... #} is
> already restricted to single-line comments, so there are no multi-line
> comments that would break. Plus, I'd wager it could be implemented
> quite efficiently.
>
> What do you think?
>
> Tobia
>

I'd be strongly -1 on anything that makes template language look more like m4!

Having said that, I can see this being useful. We use templates to
render most kinds of output. When we render text emails, the newlines
and indentation are particularly important, as everything gets
displayed 'as-is' by the client, and having a template that is
readable and also renders correctly is tricky.

Generally where this happens is where we open a block level tag, and
would then normally have a newline for readability, but cannot due to
us not wanting a newline to appear. This could be addressed by having
a different open/close tag for tags which chomp the preceeding/next
character if it is a newline. Eg:

In your folder are:
{^ for item in folder ^}
{{ item }},
{^ endfor ^}

This would render as "In your folder are: item1,item2,item3,"

Changing some of the carets:

In your folder are:
{% for item in folder ^}
{{ item }},
{^ endfor %}

This would render as "In your folder are:\nitem1,item2,item3,\n"

I'm not 100% convinced though.

Cheers

Tom

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

[Daniel Moisset]

On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch  wrote:
>> This thread contains 6 people expressing support for this change, and 2 
>> against (a BDFL, a core developer) -- and you can add me to the -0 list. 
>> There are over 6000 subscribers to django-developers. I put it to you that 
>> the vast majority of people haven't expressed an opinion -- and many of 
>> those haven't expressed an opinion because they're happy with (or 
>> indifferent to) the status quo, and a BDFL has already indicated that the 
>> status quo is his preferred option.
>
> You asked for it, so here is my +1.
>

And mine; even if I might have needed multiline tags once or twice in
several years, I think it's perfectly reasonable, and the current
behaviour non-intuitive.

+1

D.

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

[Alex Gaynor]

On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset wrote:

> On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch  wrote:
> >> This thread contains 6 people expressing support for this change, and 2
> against (a BDFL, a core developer) -- and you can add me to the -0 list.
> There are over 6000 subscribers to django-developers. I put it to you that
> the vast majority of people haven't expressed an opinion -- and many of
> those haven't expressed an opinion because they're happy with (or
> indifferent to) the status quo, and a BDFL has already indicated that the
> status quo is his preferred option.
> >
> > You asked for it, so here is my +1.
> >
>
> And mine; even if I might have needed multiline tags once or twice in
> several years, I think it's perfectly reasonable, and the current
> behaviour non-intuitive.
>
> +1
>
> D.
>
> --
> 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.
>
>
Folks, you seem to have missed Russell's point.  Even if 100 people +1
this, it's meaningless.  That's a tiny fraction of this mailing list's
readership, much less of the Django community at large.  Django is the way
it is because, first and foremost, of taste.  If you'd like to make an
argument as to *why* it's useful, that's useful, but we don't take polls.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

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

[Daniel Moisset]

On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> it's meaningless.  That's a tiny fraction of this mailing list's readership,
> much less of the Django community at large.  Django is the way it is
> because, first and foremost, of taste.  If you'd like to make an argument as
> to *why* it's useful, that's useful, but we don't take polls.
>

It's useful because it helps some templaets in some cases be more readable

-- 
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/23/2012 11:29 PM, Russell Keith-Magee wrote:
> This thread contains 6 people expressing support for this change, and
> 2 against (a BDFL, a core developer) -- and you can add me to the -0

FWIW, I'd forgotten how painful the single-line restriction was the last
time I had to work on internationalized templates using blocktrans. The
presented use cases have me thoroughly convinced that this is an
unreasonable restriction on template authors, and I'd be +1 on lifting it.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk9HrEkACgkQ8W4rlRKtE2fRmgCgoSknqISpYN+zQbqksdgAnQBg
+ToAoNcB27Gr/S2+JZEYzq+p70eh83R9
=Z3lD
-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

[Paul Egges]

Mark me a +1 on this as well.  Many of us don't ask for items in discussion
that have been marked as "won't fix" because we don't realize that the
decisions on these items can be reversed.

Thanks,

Paul

On Fri, Feb 24, 2012 at 2:19 AM, Bradley Ayers wrote:

>
> On 24/02/2012, at 7:01 PM, Stephan Jaensch  wrote:
>
> >>> 1) It's an easy fix.
> >>> 2) It's backwards compatible.
> >>> 3) It has no impact on performance.
> >>> 4) LOTS of people want it.
> >>>
> >>> and most importantly
> >>>
> >>> 5) We could stop asking for it.
> >>>
> >>> This issue is such an easy "sure, why not!?"
> >>>
> >>> Please, O benevolent dictators, listen to the populous, and heed their
> >>> cry.
> >>
> >> I can certainly appreciate the reasons why those asking for this change
> would like to see the change made, but please don't attempt to characterize
> this thread as clear and overwhelming support for change.
> >>
> >> This thread contains 6 people expressing support for this change, and 2
> against (a BDFL, a core developer) -- and you can add me to the -0 list.
> There are over 6000 subscribers to django-developers. I put it to you that
> the vast majority of people haven't expressed an opinion -- and many of
> those haven't expressed an opinion because they're happy with (or
> indifferent to) the status quo, and a BDFL has already indicated that the
> status quo is his preferred option.
> >
> > You asked for it, so here is my +1.
> >
> >> This is also the first time the issue has been raised on django-dev for
> some time -- I can't even remember the last time the subject was raised. If
> this is such a demand of the populous, why isn't it a regular topic of
> discussion on django-dev?
> >
> > Because the Django community is extremely nice and well-behaved...? :) I
> too was unhappy with the decision, but didn't feel it was important enough
> to post in this thread. That doesn't mean I wouldn't appreciate multiline
> tags.
> >
> >> Finally, your arguments in favor of making this change are almost
> entirely technical -- easy fix, backwards compatible, no performance hit.
> However, you've missed the non-technical aspects -- that introducing
> multiline tags would fundamentally change the flavor of Django templates.
> Part of the job of the BDFLs is to make aesthetic choices. As indicated by
> Adrian in his response, this is largely an aesthetic decision on his part.
> Aesthetic choices aren't always popular, and almost by definition won't
> make everyone happy, but they are an essential part of what gives Django
> it's distinctive flavor.
> >
> > Well, and you are really making the non-technical argument for the
> supporters, aren't you? If multiline tags would fundamentally change the
> flavor of Django templates, it would mean that suddenly people everywhere
> would start using them, massively. This would mean there is overwhelming
> demand for them. But if people do only use them in the cases where it's
> appropriate (e.g. the dreaded trans tag, multi-line comments and so forth)
> then it doesn't change much of anything and just makes templates more
> readable.
> >
> > I understand this is an aesthetic decision. I just wish to point out
> that you can't make the argument that nobody wants it and that it would
> also have a big impact.
> >
> > Cheers,
> > Stephan
>
> In the interest of making the wider community opinion heard, I too am +1
> on this, my feeling is exactly the same as 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-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 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

[Tom Evans]

On Fri, Feb 24, 2012 at 3:12 PM, Alex Gaynor  wrote:
> Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> it's meaningless.  That's a tiny fraction of this mailing list's readership,
> much less of the Django community at large.  Django is the way it is
> because, first and foremost, of taste.  If you'd like to make an argument as
> to *why* it's useful, that's useful, but we don't take polls.

I think all the arguments have been stated, and quite well.

So, how many people have to disagree with a BDFL before something will
be reconsidered? I do understand what the 'D' in BDFL stands for…

Perhaps it would be better for the reasons for rejecting this change
to be made clear. Russell alludes to this being an aesthetic decision.
I am no aesthete, so for those of us not so gifted, can you explain
why having multiline capable tags would ruin the beauty of django?

Cheers

Tom

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

[Daniel Sokolowski]

+1 and reason as previously stated: it makes sense to brake down very long tags 
for readability purposes. 
From: Alex Gaynor 
Sent: Friday, February 24, 2012 10:12 AM
To: django-developers@googlegroups.com 
Subject: Re: Revisiting multiline tags




On Fri, Feb 24, 2012 at 10:01 AM, Daniel Moisset  
wrote:

  On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch  wrote:
  >> This thread contains 6 people expressing support for this change, and 2 
against (a BDFL, a core developer) -- and you can add me to the -0 list. There 
are over 6000 subscribers to django-developers. I put it to you that the vast 
majority of people haven't expressed an opinion -- and many of those haven't 
expressed an opinion because they're happy with (or indifferent to) the status 
quo, and a BDFL has already indicated that the status quo is his preferred 
option.
  >
  > You asked for it, so here is my +1.
  >


  And mine; even if I might have needed multiline tags once or twice in
  several years, I think it's perfectly reasonable, and the current
  behaviour non-intuitive.

  +1

  D.


  --
  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 
mailto:django-developers%2bunsubscr...@googlegroups.com.
  For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Folks, you seem to have missed Russell's point.  Even if 100 people +1 this, 
it's meaningless.  That's a tiny fraction of this mailing list's readership, 
much less of the Django community at large.  Django is the way it is because, 
first and foremost, of taste.  If you'd like to make an argument as to *why* 
it's useful, that's useful, but we don't take polls. 

Alex


-- 
"I disapprove of what you say, but I will defend to the death your right to say 
it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero


-- 
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 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.4b + mysql + boolean fields

[Aymeric Augustin]

Please go ahead, create a ticket and set its severity to "release blocker".

Assuming a proper test was added with the fix for #13293, that test should
fail on the geographic version of mysql. Unfortunately we don't have this
engine on the CI server at this time. I'll try to add it.

Thanks for your feedback,

-- 
Aymeric.


2012/2/24 Tomasz Kloc 

> The problem was caused by django.contrib.gis.db.**backends.mysql backend.
> It has own backend implementation which returns booleans as integers (it
> was fixed for 'core' mysql backend in https://code.djangoproject.**
> com/ticket/13293  )
>
> I think it's a bug which will afect some users after upgrading to django
> 1.4 - in my opinion quite serious.
>
> Any comments before creating a ticket?
>
>
>
> On 24.02.2012 11:25, Tomasz Kloc wrote:
>
>> Ticket with change described below: https://code.djangoproject.**
>> com/ticket/17114 
>>
>> I've also found that since Django 1.2 (https://docs.djangoproject.**
>> com/en/dev/releases/1.2/#**booleanfield-on-mysql)
>> booleans in mysql backend should be returned as True/False, but i still get
>> ints values.
>>
>> In [7]: AuctionCategoryCustomField.**objects.all()[0].enable_**
>> search_filter
>> Out[7]: 1
>>
>> environment:
>> In [6]: sys.version
>> Out[6]: '2.6.6 (r266:84292, Dec 26 2010, 22:31:48) \n[GCC 4.4.5]'
>>
>> In [7]: django.VERSION
>> Out[7]: (1, 3, 1, 'final', 0)
>>
>> On 24.02.2012 11:00, Tomasz Kloc wrote:
>>
>>> Hello,
>>>
>>> I've changed my database from postgresql to mysql. I have never used
>>> mysql in django projects before, so it was surprising to me when i saw 0/1
>>> values instead of True/False in boolean fields. It wasn't an issue until i
>>> upgraded django from 1.3.1 to 1.4b.  After that, all boolean fields in
>>> admin interface are checked (in edit mode). They are rendered as:
>>>
>>> >> name="checkbox_filter" checked="checked">
>>>
>>> i've looked into forms.widgets.CheckboxInput in both django versions and
>>> noticed some logic changes when checking value:
>>>
>>> (1.3.1)
>>>
>>> def __init__(self, attrs=None, check_test=bool):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
self.check_test = check_test

>>>
>>> (1.4b)
>>>
>>>
def __init__(self, attrs=None, check_test=None):
super(CheckboxInput, self).__init__(attrs)
# check_test is a callable that takes a value and returns True
# if the checkbox should be checked for that value.
if check_test is None:
self.check_test = lambda v: not (v is False or v is None or
 v == '')
else:
self.check_test = check_test

>>>
>>> in this case "0" is treated as True.
>>>
>>> Is this a bug?
>>>
>>> regards,
>>> tomasz kloc
>>>
>>>
>>>
>>>
> --
> 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+unsubscribe@**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-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.4b + mysql + boolean fields

[Carl Meyer]

Hello Tomasz,

On 02/24/2012 03:00 AM, Tomasz Kloc wrote:
> I've changed my database from postgresql to mysql. I have never used
> mysql in django projects before, so it was surprising to me when i saw
> 0/1 values instead of True/False in boolean fields. It wasn't an issue
> until i upgraded django from 1.3.1 to 1.4b.  After that, all boolean
> fields in admin interface are checked (in edit mode).

If I am not mistaken, this was already reported in ticket #17747
(https://code.djangoproject.com/ticket/17747). It had been closed as
"worksforme" because the original reporter didn't realize the problem
was specifically related to use of MySQL (and, it seems, the MySQL GIS
backend). Thanks for the additional information!

Carl



signature.asc
Description: OpenPGP digital signature

Re: django 1.4b + mysql + boolean fields

[Aymeric Augustin]

I just noticed that #17747 was reopened for this purpose, so there's no
need for another ticket.

Best regards,

-- 
Aymeric.

2012/2/24 Aymeric Augustin 

> Please go ahead, create a ticket and set its severity to "release blocker".
>
> Assuming a proper test was added with the fix for #13293, that test should
> fail on the geographic version of mysql. Unfortunately we don't have this
> engine on the CI server at this time. I'll try to add it.
>
> Thanks for your feedback,
>
> --
> Aymeric.
>
>
> 2012/2/24 Tomasz Kloc 
>
>> The problem was caused by django.contrib.gis.db.**backends.mysql
>> backend. It has own backend implementation which returns booleans as
>> integers (it was fixed for 'core' mysql backend in
>> https://code.djangoproject.**com/ticket/13293)
>>
>> I think it's a bug which will afect some users after upgrading to django
>> 1.4 - in my opinion quite serious.
>>
>> Any comments before creating a ticket?
>>
>>
>>
>> On 24.02.2012 11:25, Tomasz Kloc wrote:
>>
>>> Ticket with change described below: https://code.djangoproject.**
>>> com/ticket/17114 
>>>
>>> I've also found that since Django 1.2 (https://docs.djangoproject.**
>>> com/en/dev/releases/1.2/#**booleanfield-on-mysql)
>>> booleans in mysql backend should be returned as True/False, but i still get
>>> ints values.
>>>
>>> In [7]: AuctionCategoryCustomField.**objects.all()[0].enable_**
>>> search_filter
>>> Out[7]: 1
>>>
>>> environment:
>>> In [6]: sys.version
>>> Out[6]: '2.6.6 (r266:84292, Dec 26 2010, 22:31:48) \n[GCC 4.4.5]'
>>>
>>> In [7]: django.VERSION
>>> Out[7]: (1, 3, 1, 'final', 0)
>>>
>>> On 24.02.2012 11:00, Tomasz Kloc wrote:
>>>
 Hello,

 I've changed my database from postgresql to mysql. I have never used
 mysql in django projects before, so it was surprising to me when i saw 0/1
 values instead of True/False in boolean fields. It wasn't an issue until i
 upgraded django from 1.3.1 to 1.4b.  After that, all boolean fields in
 admin interface are checked (in edit mode). They are rendered as:

 >>> name="checkbox_filter" checked="checked">

 i've looked into forms.widgets.CheckboxInput in both django versions
 and noticed some logic changes when checking value:

 (1.3.1)

 def __init__(self, attrs=None, check_test=bool):
>super(CheckboxInput, self).__init__(attrs)
># check_test is a callable that takes a value and returns True
># if the checkbox should be checked for that value.
>self.check_test = check_test
>

 (1.4b)


>def __init__(self, attrs=None, check_test=None):
>super(CheckboxInput, self).__init__(attrs)
># check_test is a callable that takes a value and returns True
># if the checkbox should be checked for that value.
>if check_test is None:
>self.check_test = lambda v: not (v is False or v is None or
> v == '')
>else:
>self.check_test = check_test
>

 in this case "0" is treated as True.

 Is this a bug?

 regards,
 tomasz kloc




>> --
>> 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+unsubscribe@**googlegroups.com
>> .
>> For more options, visit this group at http://groups.google.com/**
>> group/django-developers?hl=en
>> .
>>
>>
>
>


-- 
Aymeric.

-- 
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.4b + mysql + boolean fields

[Ramiro Morales]

On Fri, Feb 24, 2012 at 7:53 AM, Tomasz Kloc  wrote:
> The problem was caused by django.contrib.gis.db.backends.mysql backend. It
> has own backend implementation which returns booleans as integers (it was
> fixed for 'core' mysql backend in
> https://code.djangoproject.com/ticket/13293 )
>
> I think it's a bug which will afect some users after upgrading to django 1.4
> - in my opinion quite serious.
>
> Any comments before creating a ticket?

I think there is one already:

https://code.djangoproject.com/ticket/15169

-- 
Ramiro Morales

-- 
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: Newline stripping in templates: the dnl way

[Aron Griffis]

On Fri, Feb 24, 2012 at 9:45 AM, Tom Evans  wrote:
> In your folder are:
> {^ for item in folder ^}
> {{ item }},
> {^ endfor ^}
>
> This would render as "In your folder are: item1,item2,item3,"
>
> Changing some of the carets:
>
> In your folder are:
> {% for item in folder ^}
> {{ item }},
> {^ endfor %}
>
> This would render as "In your folder are:\nitem1,item2,item3,\n"

Fwiw, I had a different solution to this problem once, which I implemented
in a project using jinja to generate configuration files:

1. Prior to processing the template, replace all blank lines with a
   tag (e.g. "BLANKLINE").

2. After processing the template, remove all blank lines.

3. Remove all instances of BLANKLINE, which restores the blank lines
   the author intended.

This works remarkably well, and the output is easy to predict by the
template author. For the case you mentioned above, you would still need to
join the lines, though:

{% for item in folder %}{{ item }},{% endfor %}

Aron

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

[Łukasz Rekucki]

With all the voting and aesthetic discussion, maybe let's get back to
technical details:

On 24 February 2012 05:18, colinta  wrote:
> 1) It's an easy fix.

Maybe it is, I can only judge a specific patch,

> 2) It's backwards compatible.

Right now, tags are free to parse the tag contents any way they like.
You don't know if presence of EOF won't brake them or do we normalize
the EOF to spaces ?

> 3) It has no impact on performance.

Given 2) and no benchmark data, we don't really know.

> 4) LOTS of people want it.
>

That's never a good argument. If it was such a big issue, that LOTS
would either spam this list or fork Django long ago.

With a clear BDFL veto, it's better to search for an alternate
solution then waste everyone's energy on a bikeshed.

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

[Łukasz Rekucki]

On 24 February 2012 17:29, Łukasz Rekucki  wrote:
> With all the voting and aesthetic discussion, maybe let's get back to
> technical details:
>
> On 24 February 2012 05:18, colinta  wrote:
>> 1) It's an easy fix.
>
> Maybe it is, I can only judge a specific patch,
>
>> 2) It's backwards compatible.
>
> Right now, tags are free to parse the tag contents any way they like.
> You don't know if presence of EOF won't brake them or do we normalize
> the EOF to spaces ?

I meant EOL of course.

-- 
Ł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-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: Newline stripping in templates: the dnl way

[mjl Martin J. Laubach]

For this (avoiding newlines) the currently discussed multiline 
tags
 would work pretty well too without adding more cruft to the template 
language:

foo bar {#
#}baz 


mjl 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/R-wdFVTvxGAJ.
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: Newline stripping in templates: the dnl way

[Aymeric Augustin]

2012/2/24 mjl Martin J. Laubach 

> For this (avoiding newlines) the currently discussed multiline 
> tags
>  would work pretty well too without adding more cruft to the template
> language:
>
> foo bar {#
> #}baz
>
>
>
Martin,

You just made a strong argument against multiline tags: I wouldn't want to
see them abused this way!

-- 
Aymeric.

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

[h3]

> If you'd like to make an argument as to *why* it's useful, that's useful, but 
> we don't take polls.

I think the argument as to why it's useful as been made quite
extensively.

On the flip side, beside the ivory tower philosophical stance, I did
not see much
compelling argument as to *why* this is a bad idea.

If you think it makes your templates look ugly, well just don't use
it. You'd still have the choice.

Meanwhile some other people think it would make their templates more
readable, but
unfortunately they don't have the luxury to choose because an
architect think it's ugly.

At this point I think it's worth mentioning that it's a not a beauty
contest. And even if it was,
I don't see the beauty in lines of code that are 10 feet long.


On Feb 24, 10:15 am, Daniel Moisset  wrote:
> On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> > Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> > it's meaningless.  That's a tiny fraction of this mailing list's readership,
> > much less of the Django community at large.  Django is the way it is
> > because, first and foremost, of taste.  If you'd like to make an argument as
> > to *why* it's useful, that's useful, but we don't take polls.
>
> It's useful because it helps some templaets in some cases be more readable

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

[Alex Gaynor]

On Fri, Feb 24, 2012 at 12:06 PM, h3  wrote:

> > If you'd like to make an argument as to *why* it's useful, that's
> useful, but we don't take polls.
>
> I think the argument as to why it's useful as been made quite
> extensively.
>
> On the flip side, beside the ivory tower philosophical stance, I did
> not see much
> compelling argument as to *why* this is a bad idea.
>
>
Django is nothing other than ivory tower philosophies (and I really hate
this "ivory tower" insult, as if it's a bad thing to be principled and
philosophically sound) applied to APIs.  If it violates the philosophy, it
shouldn't go into an API.


> If you think it makes your templates look ugly, well just don't use
> it. You'd still have the choice.
>
>
No.  If it's an API, it doesn't need to be used by me in order to poison my
experience with Django.


> Meanwhile some other people think it would make their templates more
> readable, but
> unfortunately they don't have the luxury to choose because an
> architect think it's ugly.
>
> At this point I think it's worth mentioning that it's a not a beauty
> contest. And even if it was,
> I don't see the beauty in lines of code that are 10 feet long.
>
>
In another thread someone had an example of a multi-line tag, and I
actually commented to my computer on how ugly I found it. Beauty may be in
the eyes of the beholder, but the reason we have BDFLs is to keep those
decisions consistent.  Glyph Lefkowitz's keynote from DjangoCon this year
really drives this home.


>
> On Feb 24, 10:15 am, Daniel Moisset  wrote:
> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor 
> wrote:
> >
> > > Folks, you seem to have missed Russell's point.  Even if 100 people +1
> this,
> > > it's meaningless.  That's a tiny fraction of this mailing list's
> readership,
> > > much less of the Django community at large.  Django is the way it is
> > > because, first and foremost, of taste.  If you'd like to make an
> argument as
> > > to *why* it's useful, that's useful, but we don't take polls.
> >
> > It's useful because it helps some templaets in some cases be more
> readable
>
> --
> 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.
>
>
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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: Newline stripping in templates: the dnl way

[Tobia]

Tai Lee wrote:
> I don't think adding {# to the end of lines is easy to understand at a
> glance, it doesn't even convey a hint of meaning like "dnl" does

I beg to differ.  {# is already recognized by template authors as
meaning "start of comment", and they know (or should know) that it
cannot extend through more than one line.  Therefore I'd think it
intuitive that it will "eat" till the end of the line and not beyond.

Look:

Here are your subscriptions:
{% for thing in things %}{#
 - {{ thing.name }}
   You added it on {{ thing.date }}
{% endfor %}{#
you can manage your subscriptions...

Tom Evans wrote:
> I'd be strongly -1 on anything that makes template language look more
> like m4!

I'll tell you, m4 can be quite addictive once you grasp the basics! :)

> This could be addressed by having a different open/close tag for tags
> which chomp the preceeding/next character if it is a newline. Eg:
> {^ for item in folder ^}

I don't think adding new reserved characters would make the language
simpler for template authors, nor for the the template parser, nor for
the sake of backwards compatibility.  {# is already part of it.

But I can see the need to chomp whitespace before a template tag, as
well as the newline after it.

Martin J. Laubach wrote:
> For this (avoiding newlines) the currently discussed multiline tags
> would work pretty well too without adding more cruft to the template
>language:
>
> foo bar {#
> #}baz

If this can be accomplished without massive performance penalties, I
agree with you.

Maybe {# #} could be made multiline at first, with special code, while
waiting for a proper implementation of generic multiline tags.  This
would certainly be more forward-compatible than my proposal above
and it would solve more whitespace problems, if not all.

Tobia

-- 
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: Newline stripping in templates: the dnl way

[Jonathan French]

Jinja implements whitespace control by putting a minus sign after/before
the % in a tag - http://jinja.pocoo.org/docs/templates/#whitespace-control -
I haven't tried it myself, but it looks like {% tag -%} is equivalent to
your {% tag %}{# .

On 24 February 2012 17:37, Tobia  wrote:

> Tai Lee wrote:
> > I don't think adding {# to the end of lines is easy to understand at a
> > glance, it doesn't even convey a hint of meaning like "dnl" does
>
> I beg to differ.  {# is already recognized by template authors as
> meaning "start of comment", and they know (or should know) that it
> cannot extend through more than one line.  Therefore I'd think it
> intuitive that it will "eat" till the end of the line and not beyond.
>
> Look:
>
> Here are your subscriptions:
> {% for thing in things %}{#
>  - {{ thing.name }}
>   You added it on {{ thing.date }}
> {% endfor %}{#
> you can manage your subscriptions...
>
> Tom Evans wrote:
> > I'd be strongly -1 on anything that makes template language look more
> > like m4!
>
> I'll tell you, m4 can be quite addictive once you grasp the basics! :)
>
> > This could be addressed by having a different open/close tag for tags
> > which chomp the preceeding/next character if it is a newline. Eg:
> > {^ for item in folder ^}
>
> I don't think adding new reserved characters would make the language
> simpler for template authors, nor for the the template parser, nor for
> the sake of backwards compatibility.  {# is already part of it.
>
> But I can see the need to chomp whitespace before a template tag, as
> well as the newline after it.
>
> Martin J. Laubach wrote:
> > For this (avoiding newlines) the currently discussed multiline tags
> > would work pretty well too without adding more cruft to the template
> >language:
> >
> > foo bar {#
> > #}baz
>
> If this can be accomplished without massive performance penalties, I
> agree with you.
>
> Maybe {# #} could be made multiline at first, with special code, while
> waiting for a proper implementation of generic multiline tags.  This
> would certainly be more forward-compatible than my proposal above
> and it would solve more whitespace problems, if not all.
>
> Tobia
>
> --
> 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 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

[Jonathan French]

On 24 February 2012 17:16, Alex Gaynor  wrote:

>
>
> On Fri, Feb 24, 2012 at 12:06 PM, h3  wrote:
>
>> > If you'd like to make an argument as to *why* it's useful, that's
>> useful, but we don't take polls.
>>
>> I think the argument as to why it's useful as been made quite
>> extensively.
>>
>> On the flip side, beside the ivory tower philosophical stance, I did
>> not see much
>> compelling argument as to *why* this is a bad idea.
>>
>>
> Django is nothing other than ivory tower philosophies (and I really hate
> this "ivory tower" insult, as if it's a bad thing to be principled and
> philosophically sound) applied to APIs.  If it violates the philosophy, it
> shouldn't go into an API.
>
>
>> If you think it makes your templates look ugly, well just don't use
>> it. You'd still have the choice.
>>
>>
> No.  If it's an API, it doesn't need to be used by me in order to poison
> my experience with Django.
>

*How* does it "poison your experience"? Just the knowledge that someone,
somewhere isn't writing code to your linebreak style?


>
>> Meanwhile some other people think it would make their templates more
>> readable, but
>> unfortunately they don't have the luxury to choose because an
>> architect think it's ugly.
>>
>> At this point I think it's worth mentioning that it's a not a beauty
>> contest. And even if it was,
>> I don't see the beauty in lines of code that are 10 feet long.
>>
>>
> In another thread someone had an example of a multi-line tag, and I
> actually commented to my computer on how ugly I found it. Beauty may be in
> the eyes of the beholder, but the reason we have BDFLs is to keep those
> decisions consistent.  Glyph Lefkowitz's keynote from DjangoCon this year
> really drives this home.
>

What is the no-linebreak behaviour consistent with?


>
>
>>
>> On Feb 24, 10:15 am, Daniel Moisset  wrote:
>> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor 
>> wrote:
>> >
>> > > Folks, you seem to have missed Russell's point.  Even if 100 people
>> +1 this,
>> > > it's meaningless.  That's a tiny fraction of this mailing list's
>> readership,
>> > > much less of the Django community at large.  Django is the way it is
>> > > because, first and foremost, of taste.  If you'd like to make an
>> argument as
>> > > to *why* it's useful, that's useful, but we don't take polls.
>> >
>> > It's useful because it helps some templaets in some cases be more
>> readable
>>
>> --
>> 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.
>>
>>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>  --
> 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 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

[Michael Elsdörfer]

> Folks, you seem to have missed Russell's point.  Even if 100 people +1
> this, it's meaningless.  That's a tiny fraction of this mailing list's
> readership, much less of the Django community at large.

If the maintainers of Django want to make a personal taste-based
decision rather than a popular one, that's fair enough. But lots of
people +1'ing certainly shouldn't be considered meaningless. No one on
this list wants all 6000 subscribers to chime in with a vote. Whenever
an opinion is expressed here, there will be twenty people who agree in
silence, but feel no need to spam the list, as Shawn already pointed
out.

I think it's clear that this is a feature that is not crucial, but has
considerable support, with no one really being strongly opposed (I'm
mostly seeing -0s).

Michael

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

integration of sphinx documentation in a website a la https://www.djangoproject.com/

[d b]

Hi,

I just got started using Sphinx to generate documentation, and am loving 
it.. beautiful and (relatively) painless. I am interested in making a 
website using a Python framework (probably Flask) that includes some 
Sphinx-generated documention, and am thinking about different ways to 
accomplish that nicely.. I noticed that the main Django website integrates 
Sphinx documentation quite seamlessly. Would someone familiar with the 
pipeline be so kind as to give me an overview of how you generate and 
integrate your documentation?

Thanks,

Dalton

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/lTBhIYzL5A4J.
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: integration of sphinx documentation in a website a la https://www.djangoproject.com/

[Florian Apolloner]

Hey,

did you know that the webpage is opensource? You can take a look yourself: 
https://github.com/django/djangoproject.com

Cheers,
Florian

On Friday, February 24, 2012 10:33:54 PM UTC+1, d b wrote:
>
> Hi,
>
> I just got started using Sphinx to generate documentation, and am loving 
> it.. beautiful and (relatively) painless. I am interested in making a 
> website using a Python framework (probably Flask) that includes some 
> Sphinx-generated documention, and am thinking about different ways to 
> accomplish that nicely.. I noticed that the main Django website integrates 
> Sphinx documentation quite seamlessly. Would someone familiar with the 
> pipeline be so kind as to give me an overview of how you generate and 
> integrate your documentation?
>
> Thanks,
>
> Dalton
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/x3EWHyM0XKEJ.
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: Newline stripping in templates: the dnl way

[Florian Apolloner]

Hi,

On Friday, February 24, 2012 7:48:29 PM UTC+1, ojno wrote:
>
> Jinja implements whitespace control by putting a minus sign after/before 
> the % in a tag - http://jinja.pocoo.org/docs/templates/#whitespace-control - 
> I haven't tried it myself, but it looks like {% tag -%} is equivalent to 
> your {% tag %}{# .
>

Yes it is, and why nicer and more readable imo, using {# #} to achieve that 
effect is a horrible idea imo. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/daZiFPvKwnkJ.
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: Newline stripping in templates: the dnl way

[Florian Apolloner]

s/why/way/ 

sry :(

On Friday, February 24, 2012 11:47:21 PM UTC+1, Florian Apolloner wrote:
>
> Hi,
>
> On Friday, February 24, 2012 7:48:29 PM UTC+1, ojno wrote:
>>
>> Jinja implements whitespace control by putting a minus sign after/before 
>> the % in a tag - 
>> http://jinja.pocoo.org/docs/templates/#whitespace-control - I haven't 
>> tried it myself, but it looks like {% tag -%} is equivalent to your {% tag 
>> %}{# .
>>
>
> Yes it is, and why nicer and more readable imo, using {# #} to achieve 
> that effect is a horrible idea imo. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/34UxTDsaixQJ.
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: Newline stripping in templates: the dnl way

[Tai Lee]

Adding more symbols to existing tags (e.g. {^ for x in y ^} or {% for
x in y -%}), multi-line comment tags that don't actually include a
comment, and half baked comment tags (where the closing tag is
assumed) are all going to make templates uglier, and harder to read.

The comment tag based solutions don't even solve the problem
completely, because leading white space is still there, and users are
still required to carefully position comment tags all around block
tags to remove whitespace.

What's better about {% for x in y -%} or {^ for x in y ^} over {%
stripwhitespace on %} at the top of your template, followed by {% for
x in y %}? I think the latter is far more readable.

My ideal solution is not to add new ways to mark each individual
template tag that should have surrounding white space stripped, but to
simply enable the removal of lines that have only block tags and no
actual content. 99% of the time this is the right thing to do, and we
just need a deprecation path and new template tag so that template
authors can opt-in to the new behaviour now.

Cheers.
Tai.


On Feb 25, 4:37 am, Tobia  wrote:
> Tai Lee wrote:
> > I don't think adding {# to the end of lines is easy to understand at a
> > glance, it doesn't even convey a hint of meaning like "dnl" does
>
> I beg to differ.  {# is already recognized by template authors as
> meaning "start of comment", and they know (or should know) that it
> cannot extend through more than one line.  Therefore I'd think it
> intuitive that it will "eat" till the end of the line and not beyond.
>
> Look:
>
> Here are your subscriptions:
> {% for thing in things %}{#
>  - {{ thing.name }}
>    You added it on {{ thing.date }}
> {% endfor %}{#
> you can manage your subscriptions...
>
> Tom Evans wrote:
> > I'd be strongly -1 on anything that makes template language look more
> > like m4!
>
> I'll tell you, m4 can be quite addictive once you grasp the basics! :)
>
> > This could be addressed by having a different open/close tag for tags
> > which chomp the preceeding/next character if it is a newline. Eg:
> > {^ for item in folder ^}
>
> I don't think adding new reserved characters would make the language
> simpler for template authors, nor for the the template parser, nor for
> the sake of backwards compatibility.  {# is already part of it.
>
> But I can see the need to chomp whitespace before a template tag, as
> well as the newline after it.
>
> Martin J. Laubach wrote:
> > For this (avoiding newlines) the currently discussed multiline tags
> > would work pretty well too without adding more cruft to the template
> >language:
>
> > foo bar {#
> > #}baz
>
> If this can be accomplished without massive performance penalties, I
> agree with you.
>
> Maybe {# #} could be made multiline at first, with special code, while
> waiting for a proper implementation of generic multiline tags.  This
> would certainly be more forward-compatible than my proposal above
> and it would solve more whitespace problems, if not all.
>
> Tobia

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

[Yo-Yo Ma]

I'm -1 on this for s specific reason; If you need multiple lines for a
tag, you're doing it wrong.

>>> import this

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

Testing multidb without inconsistency

[Jeremy Dunck]

I have a master and a replica.  In test, the TEST_MIRROR on the
replica points to master.  I make writes to master, then read from
replica, then assert some numbers.

def test_stuff(self):
Foo.objects.using('master').create()
number_received = do_expensive_computations()
# Down in some guts somewhere else, a query is called like so:
# Foo.objects.using('replica').count()

And that number bubbles up eventually
assertEqual(number_received, 1)

And this fails because the master has written, but it's in a pending
transaction (enforced by TestCase as a perf optimization).

I'm not trying to test the consistency here, I'm just trying to test
that that code over there is correctly aggregating previous data.

I understand the usefulness of the TestCase perf, and I could use
TransactionTestCase, but again, I'm not trying to test transactions.
This will affect a bunch of my code (i.e. many of my tests would have
to be TransactionTestCase).

I'd like the TEST_MIRROR'd replica to have visibility to master
writes.  Right now, a new connection is opened for each alias.  It
seems to me that it would be appropriate to share the connection on
TEST_MIRROR'd DBs.  I can see that this would cause trouble if you
*wanted* to test against the visibility window, though.

What do people think might be a reasonable solution?

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